Embed Size (px)
Citation preview
Processus de developpement UML/MARTE MoPCoM pour le
codesign
Joel [email protected]
Denis [email protected]
Didier [email protected]
Resume
Dans cet article, nous presentons un flot MDEde conception de SoC (System-On-Chip) base surl’utilisation du profile UML MARTE (Modeling andAnalysis of Real-Time Embedded Systems), dediea la conception et l’analyse de systeme temps reelembarques et recemment standardise par l’OMG.Le flot presente adresse les problematiques de lacommunaute de l’ESL (Electronic System Level)et s’inscrit dans le cadre du projet MoPCoM(http ://www.mopcom.fr).
1 Introduction
Le marche des System-On-Chip connait depuisquelques annees une forte evolution. L’ITRS [ITR07]estime que d’ici a 2012, ce marche pesera 56 mil-lards de dollars, ce qui represente une croissance an-nuelle moyenne de 24%. Ce succes est du aux extra-ordinaires capacites d’integration atteintes (22 nm),conformement a la loi de Moore. Ainsi, il est pos-sible aujourd’hui d’integrer sur une puce des systemescomplets, constitues de processeurs, de memoires oude senseurs.
Malheureusement, les flots de developpements etles outils de conception n’ont pas ete aussi promptsa suivre de telles evolutions. Il en resulte aujourd’huiun gap de productivite accentue par les lois econo-miques. Les defis a relever consistent alors pour l’es-sentiel a diminuer les temps de developpement et les
couts de conception, de validation et de production.Nous pensons que l’ingenierie des modeles peut per-mettre d’atteindre ces objectifs a condition d’integrerles preoccupations de la communaute de l’ESL, a sa-voir l’exploration d’architecture rapide, la reutilisa-tion d’IP (Intellectual Properties) ou la synthese dehaut niveau. Nous verrons dans cet article que la priseen compte de telles preoccupations necessite de revoirl’approche en Y du MDA standardise par l’OMG.
Dans la section suivante, nous presentons l’etatde l’art sur les approches MDE appliques au code-sign. Nous presentons ensuite notre flot de conceptionMDA qui est base sur l’utilisation du profile UMLMARTE, dedie a la conception et l’analyse de sys-teme temps reel embarques. Nous illustrerons notreapproche sur un exemple de developpement d’un sys-teme de radio intelligente implemente sur une plate-forme FPGA.
2 Etat de l’art
La transformation des exigences du client en uneimplementation faisant de bons compromis entre lescouts et les performances est un processus com-plexe constitue de differentes activites de conception,d’analyse et de validation, et a differents niveauxd’abstraction. La bonne conduite de ces activites ne-cessite l’emploi de langages et d’outils appropries. De-puis quelques annees, la communaute de l’ESL pro-pose des solutions pour faire face aux contraintes eco-nomiques et technologiques. Par exemple, l’explora-
1
tion d’architecture permet de reduire l’espace des im-plementations possibles en fournissant au client desspecifications de systeme executables ou verifiables adifferents niveaux d’abstraction. Cette technique ite-rative permettant de reduire les risques est generale-ment couplee a d’autres techniques pour accelerer lesdeveloppements. Parmi ces techniques, on peut citer :
– La synthese de haut niveau [SVN06] qui permetde transformer des specifications fonctionnellesen architectures optimisees,
– La reutilisation d’IP qui consiste a construire dessystemes par assemblage d’IPs verifies et docu-mentes, et ce a differents niveaux d’abstractionet en supposant que les IPs aient des interfacescompatibles[KMD05],
– L’approche ”Platform Based Design” [SVCBS04]qui consiste a configurer pour des applicationsspecifiques, des plateformes generiques, compre-nants des composants reprogrammables (proces-seurs, FPGA, etc).
La modelisation de SETR necessite l’emploi d’unou de plusieurs langages dedies qui reifient lesconcepts permettant de representer les caracteris-tiques les plus pertinentes pour un niveau d’abs-traction donne. Par exemple, la notion de concur-rence est essentielle dans la representation des SETR.Dans [GT03], les auteurs soulignent quelles sontles concepts d’UML qui permettent d’exprimer laconcurrence (classes actives, AND-State, Fork, etc).On constate dans la pratique que les plateformes evo-luent plus rapidement que les fonctions qu’elles im-plementent. Aussi, dans les developpements de sys-temes d’information, beaucoup de temps est consa-cre a traiter les obsolescences. Dans ce cadre, l’ap-proche MDA [OMG03] suggerent de separer au mieuxles preoccupations et de prevoir les mecanismes per-mettant leur tissage. Dans cette approche, le modelefonctionnel est nomme CIM (Computational Inde-pendent Model), le modele d’architecture fonction-nelle est nomme PIM (platform Independent Model),le modele de plateforme est nomme PDM (plateformDeployment Model) et le modele alloue, representantl’allocation de l’architecture fonctionelle sur la plate-forme PSM (Platform Specific Model). Ainsi, les fonc-tionnalites et les plateformes peuvent evoluer de ma-niere independante. La modelisation de plateformes
presentee dans l’approche MDA necessite l’emploi deformalismes dedies. Dans [EG03], on peut trouver unexemple interessant de methodologie MDA dans le-quel les auteurs utilise UML pour modeliser l’archi-tecture fonctionnelle et introduisent de nouveaux ste-reotypes pour modeliser la plateforme. Mais la sepa-ration fonction / plateforme constitue un cas simpled’orthogonalisation des preoccupations. Elle est raffi-nee dans [CSL+] ou les auteurs soulignent la necessited’orthogonaliser differents aspects : calcul et commu-nication, fonction et architecture, comportement etperformance. Dans cet article, les auteurs presententune methodologie qui adapte l’approche ”PlatformBased Design” proposee par la communaute ESL aUML. Dans [RSRB07], les auteurs presentent une me-thodologie nommee UPES (Unified Process for Em-bedded Systems) base sur l’utilisation du profile UMLfor SystemC. Ce profile permet de reutiliser les effortsdes partenaires du consortium OSCI autour du lan-gage SystemC, derive du C++ et qui permet de de-crire des architectures materielles a differents niveauxd’abstractions (TLM PV, TLM PVT, TLM CC). En-fin, la methodologie Gaspard [PAM+08] adresse desapplications de traitement intensif du signal imple-mentees sur des grilles de processeurs, representantun type particulier de plateforme qui comprend desstructures repetitives.
Dans la section suivante, nous presentons unapercu general de notre methodologie et de l’applica-tion de Radio Intelligente qui nous a permis de validernotre approche.
3 Methodologie MoPCoM
La methodologie MoPCoM peut etre considereecomme un raffinement de l’approche MDA integrantl’exploration d’architecture, l’approche ”Platform Ba-sed Design”et la reutilisation d’IPs. Elle prend en en-tree une architecture fonctionnelle de type PIM ex-primee en SysML [OMG08]. La figure 1 donne unapercu du flot MoPCoM et met en exergue 3 niveauxde modelisation :
– Le niveau Abstract Modeling Level (AML)adresse l’expression de la concurrence et de lacommunication sans presumer de la limitation
2
des ressources,– Le niveau Execution Modeling Level (EML) defi-
nit une topologie physique abstraite permettantde faire des analyses a gros grains,
– Le niveau Detailed Modeling Level (DML) decritla plateforme de maniere detaillee et permet uneanalyse fine menant a l’implementation du sys-teme.
Fig. 1 – MoPCoM Process Overview
Pour chaque niveau, nous identifions quelles sontles sous-ensembles necessaires et suffisant d’UML etde MARTE pour realiser les activites de concep-tion, d’analyse et de validation pour chaque niveaud’abstraction. Les regles methodologiques qui en re-sultent sont saisies sous forme de contraintes Ker-Meta [MFJ05] dans un modele de processus, exprimedans un langage derive de SPEM (System and Soft-ware Process Engineering Modeling) et developpedans le cadre du projet MoPCoM.
Afin de valider notre approche, nous avons de-veloppe un systeme de radio intelligente [MJ01,HPM07] qui adapte son comportement suivantles caracteristiques de son environnement electro-magnetique (localisation, bande passante, etc). Danscet article, nous nous focaliserons sur l’etude ducas d’utilisation ”Locate Radio Access TechnologySource” qui consiste a selectionner une bande sui-vant sa charge d’utilisation et a configurer le systemeafin qu’il communique suivant le protocole correspon-dant. Le systeme est implemente sur une carte FPGAXilinx ML-506 qui comprend des composants analo-giques et numeriques.
3.1 Capture des exigences et analysefonctionnelle
Dans la mesure ou la capture, la formalisation etla traduction des exigences en architecture fonction-nelle dans le monde UML/SysML sont tres largementadressees par la litterature, nous ne nous attarderonspas sur ces points. Brievement, nous utilisons l’ap-proche ”Use Cases” pour formaliser les exigences puisl’analyse fonctionnelle permet de speficier une archi-tecture fonctionnelle flexible et reutilisable, qui ap-plique l’ensemble des bonnes pratiques (design pat-terns) pour la resolution de problemes specifiques.Par exemple, l’expression de la reconfiguration dyna-mique du systeme au niveau fonctionnel utilise le pat-tern ”Strategy”. A noter toutefois qu’a ce niveau, nousutilisons certains sous-paquetages du profile MARTE,en particulier pour l’expression des contraintes non-fonctionnelles.
Par exemple, l’expression des contraintes tempsreel utilise le paquetage ”Time” de MARTE car ilfournit un modele de temps plus fin que celui deUML. Le profile MARTE fournit egalement un lan-gage de specification de valeurs nomme VSL (ValueSpecification Language) sous forme d’un metamodeleet d’une grammaire. Ce langage extensible permetd’annoter les modeles par des contraintes portantsur des grandeurs physiques (temps, puissances, lon-gueurs, poids, etc).
Le modele PIM issu de l’analyse fonctionnelle peutetre utilise en entree d’un outil de synthese compor-tementale de haut niveau moyennant une transfor-mation de type ”model-to-text”. Le projet MoPCoMfournit de telles transformations pour les outils Cata-pultC de Mentor et GAUT developpe par le LESTER(http://web.univ-ubs.fr/lester/www-gaut/).
3.2 Abstract Modeling Level
Alors que l’analyse fonctionnelle se focalise sur lesaspects algorithmiques du systeme, ce niveau adressel’explicitation de la concurrence et de la communica-tion, generalement designee par le terme ”Modele deCalcul” (MoC – Model of Computation).
Le modele de calcul definit les regles qui regissentla concurrence et la communication. Il est caracterise
3
par au moins un modele de temps (causal, continu,discret), une representation des donnees (type de don-nees abstraits, vecteurs de bit, signal) ou un typede communication (IPC – Inter-Process Communi-cation, variables partagees, FIFO, signaux).
La definition du MoC permet de mener differentstypes d’analyse comme par exemple des analyses deperformance et d’ordonnancement ou la detectiond’inter-blocages. Le choix du MoC depend d’une partdu systeme a implementer et d’autre part du typed’analyse a realiser. Dans la mesure ou les systemesmelent generalement plusieurs modeles de calcul, ilest important de pouvoir disposer d’outils permettantla conception et l’analyse de systemes multi-Mocs.L’outil Ptolemy developpe par l’universite de Berke-ley en est un exemple.
Pour exprimer la concurrence dans UML, on peutau niveau comportemental utiliser les And-Statesdans les statecharts ou les ”fork nodes” dans les dia-grammes d’activites. Au niveau de la classe, le meta-attribut ”isActive”supporte la notion d’entite concur-rente. Il est egalement possible d’utiliser le pattern”Concurrence” dans l’architecture fonctionnelle.
Cependant, toutes ces techniques pour exprimer laconcurrence ne permettent pas de saisir les proprie-tes temps reel requis pour mener des analyses per-tinentes. A cet effet, la notion de ”RTUnit” (Real-Time Unit – Unite temps reel), fournit par le pro-file MARTE dans le paquetage ”HLAM”, supportela notion d’entite concurrente. Elle est associee aun ensemble de meta-attributs (tags) precisant lescaracteristiques temps reel. Un ”RTUnit” est definicomme un bloc qui fournit/requiert un ensemblede services temps reel (RTService) et possede aumoins un comportement temps reel (RTBehavior)avec une queue bornee / non bornee. Les comporte-ments temps reel peuvent etre decomposes en actionstemps reel (RTAction).
A ce niveau, toutes les communications sont enpoint-a-point et sont supportees par des connecteurstemps reel (RTeConnector) implementant des meca-nismes de haut niveau (put/get ou read/write).
La figure 2 illustre l’allocation d’une architecturefonctionnelle 1© sur la plateforme AML 2©. Cette pla-teforme melange 3 types de MoCs : CT (Continuous
Time), KPN (Kahn Process Network) et DE (Dis-crete Event). Les comportement specifies au niveaufonctionnel sont transformes, lors de l’allocation, encomportement temps reel 3© pour lesquels un certainnombre de caracteristiques doivent obligatoirementetre renseignes. Ces comportements doivent alors te-nir compte des mecanismes de communication sous-jacents.
Le support des MoCs est rendu possible grace al’instanciation de classes specifiques regroupes dansune librairie MoC fournit par le projet MoPCoM.Dans l’exemple de la figure 3, nous montrons com-ment le MoC KPN est supporte : pour chaque intancede ”KPNConnector” ou ”KPNPort”, une classe de lalibrairie MoC est instanciee.
Fig. 2 – Functional to AML Platform Allocation
Par ailleurs, les contraintes d’allocation peuventfaire apparaıtre dans le modele alloue des blocs spe-ciaux dedies aux multiplexages / demultiplexages dedonnees.
3.3 Execution Modeling Level
Le but du niveau EML est d’analyser l’executiondu modele AML alloue du niveau precedent sur la de-finition d’une plateforme d’execution gros grain. Lesanalyses menees a ce niveau abstraient les couts liesau materiel (CPU, FPGA) ou aux couches d’abstrac-
4
Fig. 3 – KPN MoC Support
tion (OS, Middleware) a travers des modeles statis-tiques [Kou96].
La definition de la plateforme et de l’allocation estrealisee au regard des compromis entre les perfor-mances et les couts, et a travers un processus iteratifmettant en avant la topologie de la plateforme. Latopologie regroupe les noeuds de calcul ou de memo-risation, interconnectes a travers des bus qui imple-mentent des protocoles de haut niveau. Les donneestransitees sont exprimees au bit pres et le modele detemps est approximatif.
Les ressources modelisees au niveau EML sontavant tout caracterisees par les services qu’ellesoffrent aux applications et les qualites de services as-sociees. Les ressource possedent des vitesses d’execu-tion relatives. Les contraintes temps reel sont veri-fiees grace a l’utilisation d’une horloge ideale unique(pattern singleton) mesurant la progression du tempsreel.
Les resultats des analyses consequents aux alloca-tions peuvent entrainer des refactorings au niveau desmodeles de plateforme comme au niveau du PIM.Actuellement, ce processus de refactoring est realisemanuellement et depend essentiellement des compe-tences des ingenieurs qui en ont la charge. Cepen-dant, nous pensons qu’il sera possible de prevoir parla suite des mecanismes de retro-annotation permet-tant d’automatiser l’exploration d’architecture.
Afin de modeliser la plateforme du niveau EML,
nous utilisons le paquetage GRM (Generic ResourceModeling) du profile MARTE. Ce paquetage reifieles concepts necessaires pour modeliser des entites lo-giques ou physiques persistentes. Dans ce paquetage,une ressource est caracterisee par l’ensemble de sesservices rendus aux applications et par ses proprietesnon-fonctionnelles telles que la latence, le poids ou laconsommation. Afin de proceder a des analyses grosgrains de l’utilisation des ressources, nous utilisonsegalement le paquetage GQAM (Generic Quantita-tive Analysis Modeling) et ses sous-paquetages PAM(Performance Analysis Modeling) et SAM (Schedu-ling Analysis Modeling). Ces analyses permettent no-tamment de detecter les goulots d’etranglement auniveau de bus de communication.
La figure 4 montre une vue simplifiee de l’allo-cation du modele alloue AML 1© sur la plateformeEML 2©. Cet exemple illustre une allocation sur deuxniveaux de plateforme : le premier niveau specifiela couche d’abstraction materiel (Operating System)alors que le second niveau represente la plateformephysique. L’allocation est representee par des liensde dependence stereotypes ”Allocate” specifiant la di-mension temporelle, spatiale ou hybride de l’alloca-tion. Dans cette figure, le noeud ”Supervision” re-presente un noeud de calcul en charge de la recon-figuration dynamique et caracterise par une vitesserelative egale a 1.0 4©. La couche d’abstraction estconstituee d’un ordonnanceur gerant des taches avecune politique de type EDF (Earliest Deadline First)3©. Le bus de communication implemente des primi-tives de transports possedants un certain nombre decaracteristiques non-fonctionnelles 5©. Les scenariosd’analyse mettent en exergue les debits de donnees,les latences, la memoire occupee ou les couts lies a lareconfiguration dynamique.
3.4 Detailed Modeling Level
Ce niveau vise a fournir un modele detaille de laplateforme par un raffinement des modeles du niveauprecedent. Le modele alloue de ce niveau doit conte-nir assez d’information pour permettre la generationdu code d’implementation pour les parties materielles(VHDL) ou logicielles (C), ainsi que la glue logique(pilotes) permettant l’interfacage des deux parties.
5
Fig. 4 – AML to EML Platform Allocation
Par exemple, les noeuds de calcul definis au niveauEML sont raffine en processeurs ou en FPGA, lesnoeuds de memorisation sont raffines en SRAM ouen Flash, etc. On s’interesse a ce niveau autant auxservices fournis par les ressources qu’aux caracteris-tiques physiques precis (frequence de fonctionnement,poids, prix, etc). Le raffinement de la plateforme im-plique celui des interfaces, des protocoles de commu-nication ainsi que celui du modele de temps sous-jacent. A ce niveau, les ressources sont ”clockes” etles analyses sont menees au bit pres et au cycle pres(Cycle Accurate Bit Accurate). Les couches d’abs-traction materielle deviennent des OS ou des middl-wares, et sont caracterisees par leurs API. La normePOSIX (http ://standards.ieee.org/regauth/posix/)constitue un exemple d’API.
Afin de modeliser la plateforme et les analysesa ce niveau, nous utilisons de MARTE les paque-tages DRM (Detailed Resource Modeling) et ses sous-paquetage SRM (Software Resource Modeling) etHRM (hardware Resource Modeling), conjointementavec les paquetages GQAM comme vu dans la section
precedente.
4 Gestion des metamodelesdans le processus
Le processus MoPCoM est constitue de trois ni-veaux d’abstraction avec pour chaque niveau plu-sieurs modeles : un modele d’application, un modelede plateforme, un modele d’allocation, un modelealloue et plusieurs modeles d’analyse (performance,ordonnancement, WCET, etc). Approximativement,le metamodele UML comprend environ 240 meta-classes auquelles il faut ajouter 150 stereotypes duprofile MARTE. Un des objectifs du projet MoPCoMest de fournir des regles methodologiques permettantde faciliter les activites de conception et d’analyse.Dans ce but, nous proposons une extension du pro-file SPEM appele MODAL (MOdel Driven Architec-ture Language) et qui introduit d’une part des no-tions permettant de mieux comprendre et analyser lesmethodologies et les processus de developpement ; etd’autre part, qui raffine la definition des artefacts auregard des metamodeles qui les definissent et leur as-socie la notion de cycle de vie dans le but de controlerplus finement l’execution des processus. Ainsi, chaqueactivite du processus est liee a une intention (but) etapplique une strategie (plan) conformement a l’etatde l’art du moment des outils et des langages. Dansce langage, les contraintes portant sur l’utilisationde metaclasses ou de stereotypes pour une activitedonnee sont specifies en utilisant la syntaxe du lan-gage KerMeta [MFJ05]. En outre, le langage KerMetafournit des mecanismes permettant de tisser facile-ment des contraintes et une semantique operation-nelle aux metamodeles.
5 Outillage
Le processus de codesign MoPCoM est supportepar un ensemble d’outils ”conformes” aux standardsde l’OMG (MDA, UML, MOF, XMI) ou aux tech-nologies fournies par la plateforme Eclipse (EMF,Ecore, KerMeta, MDWorkbench) : Rhapsody de Te-lelogic est utilise pour la modelisation UML de l’ap-
6
plication et des plateformes, MDWorkbench de So-dius est utilise pour les transformations (model-to-model et model-to-text) et KerMeta est utilise commeoutil de meta-modelisation pour la specification descontraintes d’utilisation du profile MARTE confor-mement aux niveaux d’abstraction AML, EML etDML.
Le langage d’action permettant de specifier le corpsdes operations ainsi que les guardes ou les actionsdans les specifications comportementales est un sous-ensemble du langage C++ complete par un ensemblede macros adressant par exemple l’envoi d’evene-ments. Ce choix est essentiellement motive par laflexibilite et l’extensibilite du langage ainsi que sa fa-cilite d’apprentissage. Le projet MoPCoM fournit unparseur permettant de remonter la syntaxe du lan-gage au niveau des modeles a des fins d’analyse et degeneration de code de plus bas niveau (VHDL ou C).
6 Conclusion
Dans cet article, nous avons presente un flot de de-veloppement pour la conception de SoC. Ce flot raf-fine le modele en Y du MDA standardise par l’OMGpour permettre l’exploration d’architecture. De plus,ce flot a ete formalise par le biais d’un modele decritpar un langage derive de SPEM. Un exemple d’appli-cation de Radio Intelligente implemente sur une pla-teforme FPGA Xilinx nous a permis de valider notreapproche. Ce travail a ete realise dans le cadre duprojet MoPCoM (http ://www.mopcom.fr), labelisepar l’Agence National de la Recherche et les poles”Image et Reseaux” et ”Cluster de clusters” des re-gions Bretagne et Pays de la Loire.
References
[CSL+] Rong Chen, Marco Sgroi, Luciano Lava-gno, Grant Martin, Alberto Sangiovanni-Vincentelli, and Jan Rabaey. Uml andplatform-based design.
[EG03] Martyn Edwards and Peter Green. Umlfor hardware and software object mode-ling. pages 127–147, 2003.
[GT03] Sebastien Gerard and Francois Terrier.Uml for real-time : which native conceptsto use ? ACM, 13 :17–51, 2003.
[HPM07] Rachid Hachemani, Jacques Palicot, andChristophe Moy. A new standard re-cognition sensor for cognitive radio ter-minals. In EURASIP, KESSARIANI,GREECE, 2007.
[ITR07] ITRS. Design. Technical report, INTER-NATIONAL TECHNOLOGY ROAD-MAP FOR SEMICONDUCTORS, 2007.
[KMD05] Ali Koudri, Samy Meftali, and Jean-LucDekeyser. IP integration in embeddedsystems modeling. In 14th IP Based SoCDesign Conference (IP-SoC 2005), Gre-noble, France, December 2005.
[Kou96] A. A. Kountouris. Safe and efficient eli-mination of infeasible execution paths inwcet estimation. In RTCSA ’96 : Procee-dings of the Third International Work-shop on Real-Time Computing SystemsApplication (RTCSA ’96), page 187, Wa-shington, DC, USA, 1996. IEEE Compu-ter Society.
[MFJ05] Pierre-Alain Muller, Franck Fleurey, andJean-Marc Jezequel. Weaving executabi-lity into object-oriented meta-languages.In Proc. of MODELS/UML, LNCS,Montego Bay, Jamaica, 2005. Springer.
[MJ01] III Mitola Joseph. Cognitive radio forflexible mobile multimedia communica-tions. Mob. Netw. Appl., 6(5) :435–441,2001.
[OMG03] OMG. Mda guide version 1.0.1. Techni-cal report, Object Management Group,2003.
[OMG08] OMG. Systems modeling language speci-fication v1.1. Technical Report ptc/2008-05-16, Object Management Group, 2008.
[PAM+08] Eric Piel, Rabie Ben Attitalah, PhilippeMarquet, Samy Meftali, Smaıl Niar,Anne Etien, Jean-Luc Dekeyser, andPierre Boulet. Gaspard2 : from marteto systemc simulation. March 2008.
7
[RSRB07] E Riccobene, P Scandurra, A Rosti, andS Bocchio. Designing a unified processfor embedded systems. In In the FourthInternational Workshop on Model-BasedMethodologies for Pervasive and Embed-ded Software (MOMPES), Braga, POR-TUGAL, March 2007. IEEE ComputerSociety.
[SVCBS04] Alberto Sangiovanni-Vincentelli, LucaCarloni, Fernando De Bernardinis, andMarco Sgroi. Benefits and challenges forplatform-based design. In DAC ’04 : Pro-ceedings of the 41st annual conference onDesign automation, pages 409–414, NewYork, NY, USA, 2004. ACM.
[SVN06] Greg Stitt, Frank Vahid, and Walid Na-jjar. A code refinement methodology forperformance-improved synthesis from c.In ICCAD ’06 : Proceedings of the 2006IEEE/ACM international conference onComputer-aided design, pages 716–723,New York, NY, USA, 2006. ACM.
8
