Eindwerk voorgedragen tot het behalen van het diploma van INDUSTRIEEL INGENIEUR INFORMATICA

Transcriptie

1 Academiejaar Departement Industriële Wetenschappen BME - CTL Schoonmeersstraat Gent Eindwerk voorgedragen tot het behalen van het diploma van INDUSTRIEEL INGENIEUR INFORMATICA Karel NIJS Promotoren: Dhr. Joachim VAN MEIRVENNE Dhr. Erwin DEUMENS (IMEC Heverlee, Leuven) Dhr. Kristof LOOTS (IMEC Heverlee, Leuven)

2

3 Academiejaar Departement Industriële Wetenschappen BME - CTL Schoonmeersstraat Gent Eindwerk voorgedragen tot het behalen van het diploma van INDUSTRIEEL INGENIEUR INFORMATICA Karel NIJS Promotoren: Dhr. Joachim VAN MEIRVENNE Dhr. Erwin DEUMENS (IMEC Heverlee, Leuven) Dhr. Kristof LOOTS (IMEC Heverlee, Leuven)

4 Copyright 2005, 2006 Karel Nijs Alle rechten voorbehouden. Dit werk mag worden verveelvoudigd en/of openbaar gemaakt door middel van druk, fotokopie, microlm, geluidsband, kleitabletten, elektronische of welke andere wijze ook, onder de volgende voorwaarden: Vermelding van de auteur. Commerciëel gebruik is niet toegelaten. Als je dit werk wijzigt en/of verdeelt, moet dit gebeuren onder dezelfde voorwaarden. De auteur is niet aansprakelijk voor eventuele fouten en onvolledigheden in dit werk. Versie 1.0 Gecompileerd op: 9 mei

5 Woord vooraf Dit eindwerk is geschreven voor het behalen van het diploma Industrieel Ingenieur Informatica aan de Hogeschool Gent, Departement Industriële Wetenschappen BME-CTL, te Gent. De tekst zelf is geschreven op het GNU/Linux platform met LATEX en afgedrukt bij IMEC. Ik heb geprobeerd een zo goed mogelijk beeld te geven van de ontwikkeling van dit eindwerk, alsook de geslaagde en mislukte dingen. Van een eindwerk moet je iets bijleren en dat heb ik ook gedaan. Deze tekst is waarschijnlijk niet foutloos. Daarom zou ik me willen excuseren voor mogelijke fouten. Graag wil ik volgende mensen nog even bedanken: Mijn ouders die met de kans gegevens hebben deze opleiding te volgen en me hierin altijd gesteund hebben. Mijn vriendin, Wendy De Zutter, voor het nalezen van de tekst en steun gedurende het hele jaar (en meer). Joachim Van Meirvenne, docent Netwerkprogrammatie aan de Hogeschool Gent en interne promotor van dit eindwerk, voor begeleiding bij de ontwikkeling en ideeën wanneer ik even niet verder kon. Mijn externe promotors, Erwin Deumens en Kristof Loots, voor de begeleiding en het vertrouwen in mij, het hele jaar lang. De FOSDEM mensen: Clif Flynt voor de unieke kans die ik kreeg om te spreken op FOSDEM. Philip Vanmontfort, Kenny Dendauw-Imbo, de gebroeders Demeyer en Bart Derycke voor het aanwezig zijn tijdens deze presentatie. Verder nog dank aan alle mensen die ik vergeten ben. Karel Nijs Gent, 9 Mei

6 Inhoudsopgave L¼st van guren vi L¼st van tabellen vii Lijst van afkortingen x I Inleiding 1 1 Inleiding Stage Eindwerk Opdracht Huidige situatie en probleemstelling 2.1 Terminologie Productieproces. 2.3 Probleemstelling Doelstellingen Doelstellingen van IMEC Extra doelstellingen (promotor Hogeschool Gent) Overzicht mogelijke opties en uitbreidingen Controleren van een GDS-le aan de hand van een rules le Vooraf Controle zelf Uitvoer Uitvoeren van een check met Calibre Verschillende stappen Besluit II GUI 13 3 Tcl/Tk GUI Vooraf Tcl/Tk Tcl uitbreidingen i

7 3.1.3 Tix Keuze van opslagstructuur GDS-les Tcl main GUI Conguratie van GUI Listboxen voor selectie van specicaties Uitvoering checks Command line options Editeren rules le Wachtrij Check monitoring Annuleren van checks Foutafhandeling Codedocumentatie EDA speciek Calibre Rules le Executie Rapportgeneratie Clean up Dracula Rules le Executie Rapportgeneratie Clean up III Netwerklaag 39 5 Netwerklaag: algemeen en beveiliging Inleiding Situtatieschets Remote execution met SSH Oplossingen voor interactief inloggen met SSH Problemen bij SSH executie Signalen opvangen Remote executie via een service Uitvoeren via een C module met rexec() Uitvoeren via aangemaakt script Besluit Protocol Plaats in OSI-model Verschillende statussen Sequentienummers Beveiliging Vooraf ii

8 5.5.2 Doorgeven commando's van de Tcl GUI naar de Tcl C extensie Verkeer tussen client en server Server service op poort x Uitvoeren van commando's Output van commando's Uitvoeromgeving Netwerklaag: implementatie Inleiding IDE C++ debuggen Geheugenfouten en -lekken HP-UX compilatie API Namespaces en utilities Klassenmodel Debug klasse PSgen klasse Client-server model Socketlaag van de netwerklaag ASICproto laag van de netwerklaag Client ASICclient Listener Aanmaken luisteraar Conguratie luisteraar Concurrent server Bijhouden clients Afhandelen clients Opkuisen clients ASICserver startup() recv_msg() exec_cmd() kill_process() server_info() send_pid_exists() Server Opstarten server service Samenwerking met de GUI Tcl C extensie Berichten doorgeven Foutmeldingen Opstarten GUI iii

9 7 SSL implementatie SSL Algemeen SSL of TLS SSL API SSL cryptograe Certicaten Root certicatie authoriteit Generatie certicaat SSLfunctions utility namespace SSLfunctions::SSL_write() SSLfunctions::SSL_read() Certicaat controle Client SSLconn klasse PlainClient klasse SSLclient klasse Contextinitialisatie Client side session caching close_conn() Server PlainServer klasse SSLserver klasse Server side session caching Lessenpakket BIO sockets Theoretische basis Toepassingen in real life Besluit 113 Appendices 114 A Flowcharts 115 A.1 Editeren rules le A.2 Uitvoeren Calibre check 116 A.3 Check executie wachtrij B Man pages 118 B.1 runasicgui B.2 runasicserver C Installation manual 124 D Rapporten 152 D.1 Calibre. 152 D.2 Dracula iv

10 Bibliograe 158 v

11 L¼st van guren 1.1 Logo's IMEC en EUROPRACTICE De blauwdruk van een ASIC voor een camera CCD Het productieproces bij EuroPractice Tcl/Tk logo Eén van de redenen om Tix te gebruiken Directorystructuur van de beschikbare technologieën Selectie van de technologie Wachtrij met individuele starttijd voor de verschillende checks Rij voor checks in uitvoering Check Monitoring toplevel widget Vereenvoudigd proces van remote execution Plaats van de netwerklaag in het n-tier model Plaats van het onbeveiligde protocol in het OSI-model Plaats van het beveiligde protocol in het OSI-model Verschillende statussen van asicproto IConnection abstracte klasse Mogelijke implementatie van CryptConn klasse ASIChost abstracte klasse ASICclient klasse Uitvoermodel concurrent server ASICserver object model A.1 De gebeurtenis bij een klik op de Edit knop voor elke check 115 A.2 De rules le controle voor een calibre check 116 A.3 De werking van de check executie wachtrij vi

12 L¼st van tabellen 3.1 Globale Tcl variabelen Check statussen in de wachtrij Verschillende loglevels Dracula output les Protocolberichten Positionering commando's in ::nw_service::my_socket commando Opties voor cipher keuze vii

13 Lijst van Codefragmenten 3.1 eval sleutelwoord vereist Datastructuur voor keuzelijstgeneratie PDRACULA input le Volledig Dracula commando Vereenvoudigd voorbeeld van opstarten remote proces Controleren via SSH of remote PID bestaat SSH uitvoering met Perl wrapper Opbouw Calibre commando met SSH Valideren handtekening bij opstarten applicatie (pseudocode) Traditionele foutafhandeling Foutafhandeling volgens ons Debug model Networkfunctions::Gethostbyname() functie Gebruik syslog() Gebruik van abstracte klasse IConnection ASICproto bericht Gebruik van de ASICclient klasse Eciënt gebruik van een PIPE_BUF grote buer Annulatie bericht Aggressief sluiten socket Instellen socket opties Correct afsluiten socket Listener::getFreePosition() Conguratie van thread mutexen Ontvangen van clients en thread mutexen ASICserver: Uitvoeren commando's in pseudocode Executioner: Uitvoeren commando in pseudocode De kill_proces() functie Tcl aanroep van ::nw_service::my_socket Foutopvanging en foutberichtgeneratie Het runasicgui programma Keuze ciphers Beschikbare ciphers Instellen ciphers read() met timeout SSLclient::open_conn() pseudocode Instellen password callback functie viii

14 7.7 SSL client side session caching Sluiten SSL verbinding SSLserver::open_conn() pseudocode Client met SSL BIO sockets 110 D.1 Ingekort Calibre rapport 153 D.2 Dracula rapport ix

15 Lijst van afkortingen API Application Program Interface ASIC Application Specic Integrated Circuits DoS Denial Of Service DSA Digital Signature Algorithm EDA Electronic Design Automation EOC End Of Communication EOF End Of File FIFO First In First Out FOSDEM Free & Open Software Developers Meeting GUI Graphical User Interface HTML HyperText Markup Language IETF Internet Engineering Task Force IPsec Internet Protocol Security MAC Message Authentication Code OSI Open Systems Interconnection PID Process IDentier POSIX Portable Operating-System Interface for unix SSH Secure Shell SSL Secure Socket Layer TLS Transport Layer Security x

16 Deel I Inleiding 1

17 Hoofdstuk 1 Inleiding Ik ben Karel Nijs en studeer momenteel voor Industrieel Ingenieur Informatica (III) student aan de Hogeschool Gent, te Gent. Ik programmeer graag en probeer zo veel mogelijk met vrije software te werken. Zo gebruik ik altijd het GNU/Linux besturingssysteem, het OpenOce pakket en programmeer het liefst in Java, C++ en PHP. Ik heb voor een eindwerk bij IMEC gekozen omdat de uitdaging om een nieuwe (programmeer)taal te leren in deze stimulerende omgeving wel zag zitten. (a) IMEC (b) EuroPractice Figuur 1.1: Logo's IMEC en EUROPRACTICE IMEC staat voor Interuniversitair Micro-Elektronica Centrum en is een onderzoekscentrum voor moderne micro-elektronica en aanverwante domeinen. IMEC bestaat uit verschillende afdelingen met specialisaties gaande van fundamenteel onderzoek tot productie en training. Mijn stage en eindwerk gaan door bij de Industri le Vorming Micro-Electronica (INVOMEC) afdeling van IMEC. EUROPRACTICE is een prototype service voor micro-elektronica die bestaat uit de samenwerking tussen RAL, FHG en INVOMEC. EUROPRACTICE wordt gecoördineerd door INVOMEC. 2

18 Tijdens de ontwikkeling van deze applicatie voor EUROPRACTICE, werd ik door twee IMEC'ers bijgestaan: Kristof Loots en Erwin Deumens. Kristof heeft me op weg geholpen met de software, terwijl Erwin me het elektronica jargon heeft verklaard en de ontwikkeling van de GUI opvolgt. Op 25 februari 2006 heb ik de kans gehad om mijn eindwerk te presenteren op de FOSDEM meeting op de Vrije Universiteit Brussel, te Brussel. Ik heb deze mogelijkheid aangeboden gekregen van Clif Flynt, één van de schrijvers van de uitgebreide Tcl documentatie (zie (4)), na een ontmoeting op de nieuwsgroep comp.lang.tcl. Omdat het mij een unieke kans leek, heb ik deze met open armen aangenomen. De slides van de presentatie zijn beschikbaar op de bijgeleverde CD-ROM. 1.1 Stage Bij dit eindwerk was een stage van drie maanden voorzien. Ik heb deze periode mogen inkorten tot zes weken omdat ik al ervaring met het *nix besturingssysteem had. Tijdens mijn stage heb ik voornamelijk de Tcl/Tk programmeertaal aangeleerd, de EDA-software leren gebruiken en de mengelmoes van bestaande controlescripts geanalyseerd. 1.2 Eindwerk Opdracht Een ASIC is een micro-elektronica chip speciaal ontworpen voor bepaalde applicaties. In het kader van EUROPRACTICE biedt IMEC een prototype service aan voor ASIC's. AlseenklanteenideeheeftvooreenbepaaldetoepassingkanhijditlatenuitwerkentoteenGDS- le bij IMEC of zelf een GDS-le maken en naar IMEC sturen. Een GDS-le is een blauwdruk voor een ASIC. Voor men de productie van een chip kan starten, moet eerst deze blauwdruk gecontroleerd worden. Dit gebeurt aan de hand van een rules le. Deze rules le wordt door de uiteindelijke (externe) fabrikant van de chip geleverd. Hierna wordt de GDS-le gecontroleerd aan de hand van de aangepaste rules le. De controle gebeurt met verschillende software pakketten (EDA's) en moet handmatig opgestart worden. Zo'n controle van een ASIC kan 2 uur tot 2 dagen duren en is processorintensief voor de servers die de software moeten draaien. Zo kunnen er voor één ASIC verschillende checks opgestart worden. Bij het vinden van fouten moet de GDS-le door de klant aangepast worden en opnieuw worden gecontroleerd. 3

19 De bedoeling van het eindwerk is dit hele proces te automatiseren en te stroomlijnen door er een grasche user interface voor te ontwikkelen. 4

20 Hoofdstuk 2 Huidige situatie en probleemstelling Om de ontwikkeling van het project nader te verklaren, zullen we eerst de huidige situatie uitleggen. De productie en vericatie van een ASIC is een ingewikkeld proces en om de verdere tekst te begrijpen, is het noodzakelijk een blik te werpen op dit productieproces. 2.1 Terminologie ASIC Een Application Specic Integrated Circuits is een chip (IC) geschikt om een bepaalde taak. Foundry Een Foundry is een bedrijf dat (elektronica)chips produceert, bv. Philips. FAB Een FAB is de fabriek zelf waar geproduceert worde. Een typische Foundry heeft meerdere FAB's, bv. Philips Brussel. GDS-le Een GDS-le is een blauwdruk voor de productie van een ASIC. rules le Een rules le bevat de regels waaraan de blauwdruk van een ASIC moet voldoen. Zo is er bijvoorbeeld een regel dat je maar x nanometer tussen twee transistoren mag hebben. EDA Een Electronic Design Automation is software om chips mee te ontwerpen. Enkele voorbeelden: Calibre (Cadence), Dracula (Mentor), Hercules (Cadence),... check Een check of controle gaat de GDS-le controleren aan de hand van een rules le. CIF database Een resultaat database. rapport le Een rapport dat aan de klanten gegeven wordt na een uitgevoerde check. Een EDA kan meerdere soorten checks uitvoeren. Zo kunnen er bijvoorbeeld met Calibre DRC en ERC checks uitgevoerd worden. Voor elke EDA heb je een andere rules le nodig. 5

21 2.2 Productieproces Figuur 2.1: De blauwdruk van een ASIC voor een camera CCD Wanneer een klant bijvoorbeeld een chip hebben, geschikt voor een bepaald type GSM, maakt ofwel de klant de blauwdruk voor deze ASIC, ofwel geeft de klant opdracht aan EuroPratice voor het maken van deze blauwdruk. Vervolgens moet deze blauwdruk gecontroleerd worden op fouten vooraleer tot productie over gegaan kan worden. Dit is de taak van EuroPractice en gebeurt aan de hand van rules les voor een bepaalde technologie, bv. CMOS 0.8 µm. Deze rules le wordt geleverd door de Foundry zelf. Wanneer de GDS-le foutvrij en productieklaar is, wordt ze gegeven aan een FAB van de Foundry en zorgt deze FAB voor de productie. 2.3 Probleemstelling De GUI moet zo intuïtief mogelijk ontworpen zijn en makkelijk te gebruiken. Het is de bedoeling dat de hele EUROPRACTICE afdeling in IMEC er checks mee gaat uitvoeren. Er moet een analyse gebeuren van de huidige scripts (een mengeling van C-shell, Perl, sed, awk en command line) en de EDA-software zodat er eerst handmatige checks opgestart kunnen wor- 6

22 Figuur 2.2: Het productieproces bij EuroPractice den. Deze checks moeten vervolgens geautomatiseerd worden door bediening via een grasche interface. Ook zijn de checks belastend voor de servers en moet de mogelijkheid onderzocht worden of de checks op verschillende servers remote en met een bepaalde uitsteltijd (delay) kunnen opgestart worden. Het is voor IMEC vereist dat de GUI in Tcl/Tk ontworpen wordt. Omdat de keuze van de taal voor mij genomen is, zal ik onderzoeken wat de gekende voor- en nadelen van deze taal zijn en hoe deze te gebruiken/omzeilen. Het is belangrijk voor IMEC zo weinig mogelijk extra software te installeren. Door deze keuzes zijn we eventueel verplicht om eigen Tcl/Tk uitbreidingsmodules te ontwerpen in ANSI C. Om de commando's door te sturen naar de server moet er een protocol ontworpen worden die de communicatie beschrijft. Omdat de server remote commando's gaat uitvoeren, is de beveiliging van deze applicatie een kritiek punt: niet iedereen mag zomaar commando's sturen naar de server in de hoop dat ze uitgevoerd zullen worden. 7

23 2.4 Doelstellingen Doelstellingen van IMEC VoorIMECishetbelangrijkdatdeapplicatieopheteindevanhetjaarwerktenbruikklaar is. De GUI moet zo dynamisch mogelijk zijn zodat er later geen aanpassingen vereist zijn wanneer er een nieuwe Foundry of Technology toegevoegd wordt. Er moet een mogelijkheid zijn om het resultaat van een check te bekijken (rapport) en eventueel dit rapport zelf te genereren. De GUI en logica moet in één programmeertaal geschreven worden, namelijk Tcl/Tk. Omdat de gebruikte EDA-software enkel op GNU/Linux of Unix (HP-UX) kunnen uitgevoerd worden, is het vereist dat de GUI *nix compatibel is. Om versieconicten en/of niet-beschikbaarheid van modules in softwarepakketten te vermijden, wilt IMEC dat er zo weinig mogelijk andere software geïnstalleerd wordt. Op deze manier komen ze niet in de problemen met te-onderhouden licenties en updates. De GUI moet zo intuïtief mogelijk zijn: nieuwe gebruikers moeten de interface kunnen gebruiken zonder hulp 1. De broncode moet goed gedocumenteerd worden en er moet zoveel mogelijk met modules gewerkt geworden zodat de applicatie later makkelijk aanpasbaar is Extra doelstellingen (promotor Hogeschool Gent) De communicatie tussen client en server moet volgens een zelf ontworpen protocol gebeuren. De beveiliging van deze communicatie moet bestudeerd en geïmplementeerd worden Overzicht mogelijke opties en uitbreidingen Omdat de analyse en implementatie van de huidige werking van checks nogal ingewikkeld is, verwacht IMEC dat ik hier een tijdje bezig mee zal zijn. Daarom hebben ze volgende uitbreidingen voorgesteld: 1. Delayed start: checks opstarten na een bepaald uur om de workload van de servers te verlichten. 2. Remote Execution van de checks: de GUI lokaal opstarten, maar de check op een server uitvoeren. 3. Distributed checks opstarten: de check verspreiden over verschillende servers. 1 Ermoetnatuurlijkwelminimalekennisvanhethelegebeurenzijn. 8

24 4. Update van EDA-software mogelijk maken. 5. Module voor het inscannen van de topcell van een GDS-le met de GScan software. Alle uitbreidingen zijn opgenomen in mijn eindwerk. Van mijn interne promotor hebben we volgende uitbreidingen gekregen (ook: zie boven): 1. Een eigen communicatie protocol ontwerpen. 2. De client-server communicatie beveiligen. 2.5 Controleren van een GDS-le aan de hand van een rules le Het hele proces wat nu ga beschreven wordt, is sterk verschillend voor elke EDA Vooraf Voor de productie van een ASIC moet hij eerst getest worden. Dit gebeurt met een EDA, bv. Dracula. Tijdens de test worden de opgemeten waarden, genomen uit de GDS-le, vergeleken met deze in de rules le. De test software is al (centraal) geïnstalleerd. De rules le, geleverd door de klant (dit kan een zowel afdeling van IMEC zijn als een externe klant), ondergaat een kleine toevoeging van IMEC-gegevens. Alle rules les staan in een speciek geordende directorystructuur; de GDS-les staan op willekeurige plaatsen Controle zelf IMEC krijgt een zip-le opgestuurd door de klant met hierin de GDS- en andere les (niet van belang hier). Om de GDS-le te testen, zijn van belang: a) de Foundry, bv. AMIS; b) de Technology, bv. 0,7µm; c) de Options, bv. CMOS 7B. Vervolgens moet er gekozen worden welk check uitgevoerd wordt. Hier is van belang: d) het type check, bv. DRC; e) de EDA-software, bv. Dracula. 9

25 Uit de GDS-le (of eventueel de rules le) wordt de topcell (f) gehaald. Met de combinatie {a, b, c, d, e, f} kan je de correcte rules le vinden om te vergelijken/testen met de GDS-le. Opmerkingen: 1. al deze opties mogen in een cong-le bijgehouden worden voor verdere checks, 2. een GDS-le kan meerdere topcells bevatten. In de rules le wordt de naam van de GDS-le en topcell automatisch ingevuld door een al bestaand script van IMEC Uitvoer De uitvoer van het commando komt terecht in de directory waar het commando uitgevoerd wordt en resulteert in een directory die de naam van de check heeft, bv. DRC. Deze directory wordt door het controle script zelf aangemaakt en bevat menige output les, oa. het rapport, de resultaatdatabase,... Na een gelukte of mislukte check wordt, eens de rapporten verwerkt zijn, deze directory weer opgekuist. 2.6 Uitvoeren van een check met Calibre Deze sectie beschrijft het in zijn werk gaan van het eectief uitvoeren van een check. Als voorbeeld voeren we een DRC check uit van een UMC18g2 met Calibre als EDA Verschillende stappen Stap 1 De check kan in eender welke directory opgestart worden. Wanneer er bv. een DRC check uitgevoerd gaat worden, maakt men hier eerst een speciale directory voor aan zodat alle resulterende les van de check(een vijftal) hierin geplaatst worden. Stap 2 Vervolgens wordt de check opgestart met een hiervoor speciaal ontworpen script (geschreven in C-shell code). Merk op dat er nog altijd geen parameters (Foundry, Technology,...) of het type check zelf meegegeven zijn (de zo juist aangemaakte map mag eigenlijk eender welke naam hebben). 1 $ /imec/other/invosoft/software/dracula/com/cali 10

26 Opmerkingen: 1. Je moet dit script uitvoeren in de directory DRC want de paden zijn hard gecodeerd. 2. Er is een gelijkaardig script voor checks met Dracula enz. Stap 3 Wanneer het cali script start, moet je enkele parameters opgeven. Veel van deze parameters zijn hard gecodeerd en er is hier geen vrijheid in. Ook padverwijzingen naar bronles zijn reeds (half) aanwezig in de broncode. Toevoegen/wijzigen van parameters vereist een aanpassing van het script. Volgende parameters moet je ingeven: de technology (ineens een combinatie van Foundry, Technology en Options), (de locatie van) de GDS-le, een extra parameter die ontstaan is door de combinatie DRC en Calibre, de naam van de topcell. Het cali script vult dynamisch de parameters (topcell, locatie GDS-le,...) in de rules le in en voert Calibre uit. Stap 4 Wanneer het programma de check uitvoert, wordt er enige informatie naar het scherm gestuurd (waarmee niets gedaan wordt). Na het voltooien van de check is de directory gevuld met enkele les. Stap 5 De voorlopig aangemaakte (aangepaste) rules le wordt verwijderd en er wordt vervolgens nog een Perl-script opgeroepen die een rapport en CIF-database genereren Besluit Het is de aandachtige lezer misschien al opgevallen dat dit een ingewikkeld proces is. Dit is echter nog maar één EDA die we hier besproken hebben. Er zijn er zo drie. De automatisering van dit hele proces brengt verschillende voordelen met zich mee: unicatie, duidelijkheid, 11

27 modularisatie, gebruik van beperkt aantal programmeertalen. Vooral het beperkt aantal programmeertalen is een voordeel: wanneer je nu bijvoorbeeld het cali script wilt aanpassen, moet je de C-shell, Perl, sed en awk beheersen. Verder is het originele script ook niet eciënt geprogrammeerd, maar dit is eerder een gevolg van aanpassingen en uitbreidingen door de jaren heen (het cali script dateert van 1999). 12

28 Deel II GUI 13

29 Hoofdstuk 3 Tcl/Tk GUI 3.1 Vooraf Tcl/Tk Tcl 1 is een typeloze, actie geöriënteerde en geïnterpreteerde scripttaal. Als grasche subset wordt standaard Tk gebruikt. Tk sluit zo goed bij Tcl aan, dat algemeen Tcl/Tk gezegd en gebruikt wordt. Figuur 3.1: Tcl/Tk logo Tcl/Tk heeft zijn voor- en nadelen. De voordelen: de syntax heeft grote gelijkenis met deze van C(++); er zijn geen types; Tcl voorziet een uitgebreide integratie van systeemfuncties, string- en lijstbehandeling; je kan herhaaldelijk commando's in commando's plaatsen; een eenvoudige GUI is snel gebouwd met behulp van Tk; 1 Spreekuit"Tickle" 14

30 we kunnen variabelen gebruiken door variabelenamen te evalueren 2 ; voor niet-programmeurs is dit een ideale instaptaal; je kan Tcl zelf uitbreiden door of bestaande uitbreidingen te installeren, of er zelf een te schrijven in C(++). Enkele nadelen: we beschikken niet over dezelfde mogelijkheden als C++; er zijn geen types (dit is zowel een voor- als nadeel); de standaard grasche subset is te beperkt voor wat we tegenwoordig gewoon zijn 3 ; om gebruik te maken van variabelenevaluatie moet je soms trukjes uithalen; er is geen standaard objectmodel ondersteund (TclOO extensie of andere vereist); Tcl is zeer syntaxgevoelig: er zijn geen open accolades toegelaten in commentaar, verplichte spaties tussen sleutelwoorden,...; Tcl voorziet geen foutopvanging zoals Java en C++, maar we kunnen wel met een gewijzigd foutafhandelingsmodel aan de slag; geen meerdimensionale array's (zie Tabel 3.1). Meer informatie kan je vinden op Tcl uitbreidingen Tcl laat toe dat je de mogelijkheden uitbreidt met extensies. Extensies zijn packages die je op het Internet (eventueel vrij) kan downloaden en lokaal moet installeren. Vervolgens kan je deze gebruiken in het programma mbv. de package require statement. Bij de aanvang van het eindwerk werd me opgelegd geen extra software te installeren en enkel gebruik te maken van de, op de clients, geïnstalleerde Tcl en Tk versies. Ik heb mij zoveel mogelijk proberen te houden aan deze verplichting. Toen de GUI echter te onoverzichtelijk werd, heb ik toestemming gevraagd en gekregen om van de Tix extensie gebruik te maken. Bij nader inzien had ik misschien ook beter wat harder geprobeerd om de TclOO extensie te installeren zodat ik met een objectmodel de Tcl GUI had kunnen ontwerpen. 2 3 Erzijnbijvoorbeeldgeenuitschuifkeuzelijsten JavaScriptheeftdezelfdemogelijkheidmbv.de evalfunctie 15

31 3.1.3 Tix Zoals eerder vermeld is de grasche subset, Tk, beperkt in zijn mogelijkheden. Wanneer we deze zonder de Tix uitbreiding zouden gebruiken, ziet de GUI er uit alsof hij in de jaren '90 gemaakt is. Figuur 3.2: Eén van de redenen om Tix te gebruiken Ook heeft Tk standaard geen tabbladen, comboboxen, "normaal" dialoogvenster,... Om dit gebrek te overkomen, hebben we gebruik gemaakt van de Tix extensie. De Tix extensie is standaard geïnstalleerd op alle client PC's bij IMEC, enkel de servers beschikken hier niet over. Dit heeft als rechtstreeks gevolg dat de GUI enkel nog op de clients opgestart kan worden (tenzij natuurlijk de Tix extensie geïnstalleerd wordt op de servers, maar hiervoor heb ik geen toestemming). 3.2 Keuze van opslagstructuur GDS-les De GDS en rules les bevinden zich momenteel in een grote, globaal beschikbare directory waar elke normale gebruiker enkel leesrechten op heeft. Wanneer we vanuit de GUI een technologie willen kiezen, moet het browsen in deze directory via onze GUI even triviaal zijn. Daarom hebben we ervoor gekozen geen ingrijpende veranderingen door te voeren aan de huidige directorystructuur. Momenteel loopt de sortering eerst volgens Foundry, vervolgens moet je de Technology en als laatste de Options kiezen. Wanneer we ons in de Options directory bevinden, hebben we er voor gekozen om een indeling 16

32 Figuur 3.3: Directorystructuur van de beschikbare technologieën te maken volgens type check. In deze directory worden dan de GDS-le(s) geplaatst 4 en de rules le(s). Omdat er rules les van een bepaalde check voor verschillende EDA's aanwezig kunnen zijn, spreken we een extensie af waarmee de GUI kan werken. Rules les voor Dracula hebben zo bijvoorbeeld de extensie.drac. In de Options directory kunnen er ook checks niet aanwezig zijn. Als er bijvoorbeeld geen ANT check beschikbaar is, gaat er geen map zijn. Wordt er echter in de conguratie le wél de ANT check vermeld (zie 3.3.1), dan wordt deze in een andere kleur aangeduid in de GUI. Je kan dit duidelijk zien op Figuur 3.4 Op deze manier kan de gebruiker toch een ANT check opstarten met een rules le die zich op een niet-standaard plaats bevindt, ook al is hier geen rules le voor beschikbaar(in de standaard directory). Om toe te laten dat de eindgebruiker een willekeurige check met willekeurige rules le kan uitvoeren, wordt er op Foundry niveau een map, custom, aangemaakt. Wanneer de gebruiker op het Check Settings tabblad een keuze maakt in de uitschuifkeuzelijst van de EDA's wordt in de specieke directory 5 met behulp van de bestandsextensie gezocht naar een standaard rules le. Als deze rules le aanwezig is, wordt de gebruiker gevraagd of hij deze niet liever wil gebruiken. 3.3 Tcl main GUI Omdat dit project uit een groot aantal bestanden bestaat, hebben we steeds gewerkt met een aparte indeling. Je kan deze terugvinden in (Engelstalige) installatiehandleiding in Appendix C. 4 5 Somszijnermeerdereversies GespecieerddoorFoundry,Technology,OptionsenCheck 17