diff --git a/doc/img/1_format.png b/doc/img/1_format.png
new file mode 100644
index 0000000000000000000000000000000000000000..158bd53bf5d8547aa78b7253dbacb744cac5a0a6
Binary files /dev/null and b/doc/img/1_format.png differ
diff --git a/doc/img/1_gsclib.png b/doc/img/1_gsclib.png
new file mode 100644
index 0000000000000000000000000000000000000000..85947147b5b00f46083b4f258792ab788e46608e
Binary files /dev/null and b/doc/img/1_gsclib.png differ
diff --git a/doc/img/1_help.png b/doc/img/1_help.png
new file mode 100644
index 0000000000000000000000000000000000000000..c13e714240ced0d8a18a0715130bb11eb64dd4f1
Binary files /dev/null and b/doc/img/1_help.png differ
diff --git a/doc/img/1_newproj.png b/doc/img/1_newproj.png
new file mode 100644
index 0000000000000000000000000000000000000000..0cd16f916e7d0d9201943fdbd2fdbec8c90783ee
Binary files /dev/null and b/doc/img/1_newproj.png differ
diff --git a/doc/img/1_newproj_rtl.png b/doc/img/1_newproj_rtl.png
new file mode 100644
index 0000000000000000000000000000000000000000..e5be9b1f3e9d2ead30addb903e98a6a45132a651
Binary files /dev/null and b/doc/img/1_newproj_rtl.png differ
diff --git a/doc/img/1_ps.png b/doc/img/1_ps.png
new file mode 100644
index 0000000000000000000000000000000000000000..009355a831764b17c9b7f1190636c4f7b37173ae
Binary files /dev/null and b/doc/img/1_ps.png differ
diff --git a/doc/img/1_pssetup.png b/doc/img/1_pssetup.png
new file mode 100644
index 0000000000000000000000000000000000000000..115e2676ba71da8c3d74cee8e467e1bd8d38d8e7
Binary files /dev/null and b/doc/img/1_pssetup.png differ
diff --git a/doc/img/1_sdf.png b/doc/img/1_sdf.png
new file mode 100644
index 0000000000000000000000000000000000000000..d317b35546ba75376b1a3df848347bdb091ecff3
Binary files /dev/null and b/doc/img/1_sdf.png differ
diff --git a/doc/img/1_sighier.png b/doc/img/1_sighier.png
new file mode 100644
index 0000000000000000000000000000000000000000..412541c49182b3b8f14d7f0530f8ed84ccc437cd
Binary files /dev/null and b/doc/img/1_sighier.png differ
diff --git a/doc/img/1_simubeh.png b/doc/img/1_simubeh.png
new file mode 100644
index 0000000000000000000000000000000000000000..7a28376bd2cbab06604f619b6e03043d45abb791
Binary files /dev/null and b/doc/img/1_simubeh.png differ
diff --git a/doc/img/1_simupnr.png b/doc/img/1_simupnr.png
new file mode 100644
index 0000000000000000000000000000000000000000..dce2e9360bd0b37db247d35057fa07a586dd30dc
Binary files /dev/null and b/doc/img/1_simupnr.png differ
diff --git a/doc/img/1_startsimbeh.png b/doc/img/1_startsimbeh.png
new file mode 100644
index 0000000000000000000000000000000000000000..d535c26e01d46f2eb131dcd13a32d1fac3113ee6
Binary files /dev/null and b/doc/img/1_startsimbeh.png differ
diff --git a/doc/img/1_vsim.png b/doc/img/1_vsim.png
new file mode 100644
index 0000000000000000000000000000000000000000..89e25139b807d45ca11b238ce35c30042f33af10
Binary files /dev/null and b/doc/img/1_vsim.png differ
diff --git a/doc/img/2_help.png b/doc/img/2_help.png
new file mode 100644
index 0000000000000000000000000000000000000000..c53fd28eacc8495d4a8c46e3b94eb29107f5d0cb
Binary files /dev/null and b/doc/img/2_help.png differ
diff --git a/doc/img/3_floorplan.png b/doc/img/3_floorplan.png
new file mode 100644
index 0000000000000000000000000000000000000000..0122453c64d9c03e6a85fb0e9050887bfc21df9b
Binary files /dev/null and b/doc/img/3_floorplan.png differ
diff --git a/doc/img/3_globalnet.png b/doc/img/3_globalnet.png
new file mode 100644
index 0000000000000000000000000000000000000000..42736eee76c26c8a2dc2dd6bdda14d663af61309
Binary files /dev/null and b/doc/img/3_globalnet.png differ
diff --git a/doc/img/3_help.png b/doc/img/3_help.png
new file mode 100644
index 0000000000000000000000000000000000000000..e7982da648d795e064ed0edb495327bf019d7526
Binary files /dev/null and b/doc/img/3_help.png differ
diff --git a/doc/img/3_layout_pin.png b/doc/img/3_layout_pin.png
new file mode 100644
index 0000000000000000000000000000000000000000..b4d9329a4161f8cdcccfec97f724f6088638df78
Binary files /dev/null and b/doc/img/3_layout_pin.png differ
diff --git a/doc/img/3_layout_place.png b/doc/img/3_layout_place.png
new file mode 100644
index 0000000000000000000000000000000000000000..7b69bc60e17a068f6c6ee2012a71c6a668f70ba9
Binary files /dev/null and b/doc/img/3_layout_place.png differ
diff --git a/doc/img/3_layout_route.png b/doc/img/3_layout_route.png
new file mode 100644
index 0000000000000000000000000000000000000000..a998bdc52c32f606c1e61135b5060ced49e60b5d
Binary files /dev/null and b/doc/img/3_layout_route.png differ
diff --git a/doc/img/3_oalib.png b/doc/img/3_oalib.png
new file mode 100644
index 0000000000000000000000000000000000000000..c2838d2645bb7c146bf5d43c34f386794c916014
Binary files /dev/null and b/doc/img/3_oalib.png differ
diff --git a/doc/img/3_pin_top.png b/doc/img/3_pin_top.png
new file mode 100644
index 0000000000000000000000000000000000000000..951ffa3e5ea98524503b081a52d5e71cde30552c
Binary files /dev/null and b/doc/img/3_pin_top.png differ
diff --git a/doc/img/3_powerroute.png b/doc/img/3_powerroute.png
new file mode 100644
index 0000000000000000000000000000000000000000..0637dbc5fe433af7f8f00405a653273b874d1d37
Binary files /dev/null and b/doc/img/3_powerroute.png differ
diff --git a/doc/img/3_vdd_stripes.png b/doc/img/3_vdd_stripes.png
new file mode 100644
index 0000000000000000000000000000000000000000..8e458d5b2e5f935c5015ba11bc2ccfc519ef455a
Binary files /dev/null and b/doc/img/3_vdd_stripes.png differ
diff --git a/doc/img/4_dynamic_basic.png b/doc/img/4_dynamic_basic.png
new file mode 100644
index 0000000000000000000000000000000000000000..1683131d93f1c0e476e5f69777211b3cdce8964c
Binary files /dev/null and b/doc/img/4_dynamic_basic.png differ
diff --git a/doc/img/4_dynamic_run.png b/doc/img/4_dynamic_run.png
new file mode 100644
index 0000000000000000000000000000000000000000..154b275fbef540f67bb4af95f5b3659cfed22aea
Binary files /dev/null and b/doc/img/4_dynamic_run.png differ
diff --git a/doc/img/4_dynamic_setup.png b/doc/img/4_dynamic_setup.png
new file mode 100644
index 0000000000000000000000000000000000000000..eb457c42869b03a77609b1282d06d9f15abdf4e0
Binary files /dev/null and b/doc/img/4_dynamic_setup.png differ
diff --git a/doc/img/4_help.png b/doc/img/4_help.png
new file mode 100644
index 0000000000000000000000000000000000000000..199ad292be5d7b53af100ab239e6a3daf4998de9
Binary files /dev/null and b/doc/img/4_help.png differ
diff --git a/doc/img/4_pglib_setup.png b/doc/img/4_pglib_setup.png
new file mode 100644
index 0000000000000000000000000000000000000000..456217d08bca5c30274138176006813fae0a1d83
Binary files /dev/null and b/doc/img/4_pglib_setup.png differ
diff --git a/doc/img/4_restore.png b/doc/img/4_restore.png
new file mode 100644
index 0000000000000000000000000000000000000000..08a98d6fa82b907b96c157ae4e59de92d989c615
Binary files /dev/null and b/doc/img/4_restore.png differ
diff --git a/doc/img/4_static_run.png b/doc/img/4_static_run.png
new file mode 100644
index 0000000000000000000000000000000000000000..1d512452b754719b45b792d8253c2a9e874e3c30
Binary files /dev/null and b/doc/img/4_static_run.png differ
diff --git a/doc/img/4_static_setup.png b/doc/img/4_static_setup.png
new file mode 100644
index 0000000000000000000000000000000000000000..1603a38dd713e83ca83d8d38d17eaa3e578466a7
Binary files /dev/null and b/doc/img/4_static_setup.png differ
diff --git a/doc/img/compteur.zip b/doc/img/compteur.zip
new file mode 100644
index 0000000000000000000000000000000000000000..3eb9bc0cfabbaabdbe5fcad7d74ef4916f79f791
Binary files /dev/null and b/doc/img/compteur.zip differ
diff --git a/doc/sync.py b/doc/sync.py
new file mode 100644
index 0000000000000000000000000000000000000000..668d1c0ba86c36b8dfb43047ecfda5624d4cf152
--- /dev/null
+++ b/doc/sync.py
@@ -0,0 +1,49 @@
+#!/usr/bin/python3
+#-----------------------------------------------------------------------------
+# Project    : Tutoriels - Conception de circuits intégrés numériques
+#-----------------------------------------------------------------------------
+# File       : sync.py
+# Authors    : Mickael Fiorentino <mickael.fiorentino@polymtl.ca>
+# Lab        : GRM - Polytechnique Montréal
+# Date       : <2019-07-24 Wed>
+#-----------------------------------------------------------------------------
+# Description: Synchronisation de la documentation sur le Wiki du GRM
+#              - Interface à partir de l'API XML-RPC de DokuWiki
+#              --> module dokuwiki: https://python-dokuwiki.readthedocs.io
+#-----------------------------------------------------------------------------
+import dokuwiki
+import argparse
+
+# Arguments
+parser = argparse.ArgumentParser()
+parser.add_argument("login", type=str, help="Nom d'utilisateur sur le Wiki du GRM")
+parser.add_argument("passwd", type=str, help="Mot de passe sur le Wiki du GRM")
+args = parser.parse_args()
+
+# Parameters
+username  = args.login
+password  = args.passwd
+wiki_url  = 'https://intranet.grm.polymtl.ca/wiki'
+namespace = ':tutos:compteur:'
+img_dir   = 'img'
+wiki_dir  = 'wiki'
+
+# Login                                                   
+try:
+    wiki = dokuwiki.DokuWiki(wiki_url, username, password, cookieAuth=True)
+except (DokuWikiError, Exception) as err:
+    print('unable to connect: %s' % err)
+
+# Backup pages 
+pages_list = wiki.pages.list(namespace)
+for p in pages_list:
+    page = wiki.pages.get(p['id'])
+    name = wiki_dir + '/' + p['id'].split(':')[-1] + '.dwiki'
+    with open(name, 'w') as f:
+        f.write(page)
+
+# Backup Media
+media_list = wiki.medias.list(namespace)
+for m in media_list:
+    name = m['id'].split(':')[-1]
+    wiki.medias.get(m['id'], dirpath=img_dir, filename=name, overwrite=True)
diff --git a/doc/wiki/1_simulation.dwiki b/doc/wiki/1_simulation.dwiki
new file mode 100644
index 0000000000000000000000000000000000000000..f299803c42803ad1d9640d99529769469728007e
--- /dev/null
+++ b/doc/wiki/1_simulation.dwiki
@@ -0,0 +1,308 @@
+
+====== Simulation des circuits intégrés numériques ======
+
+— //[[mickael.fiorentino@polymtl.ca|Mickael Fiorentino]] 2019/07/10// —
+
+On appelle //modèle comportemental// la description matérielle d’un circuit réalisée avec un HDL. À ce niveau d’abstraction, les délais de propagation des signaux sont considérés nuls. On appelle //modèle structurel//, ou //netlist//, la description matérielle du système résultant de l'opération de synthèse. À ce niveau d’abstraction, les délais des portes et des interconnections sont pris en compte. Les informations de délai sont stockées dans un fichier ''sdf'' (//Standard Delay Format//) associé à la //netlist//, également généré par la synthèse.
+
+   * La **simulation fonctionnelle**  simule le comportement dans le temps du modèle comportemental. Elle est réalisée avant l’étape de synthèse de façon à s’assurer que le modèle comportemental respecte le cahier des charges du système. En général, la simulation fonctionnelle est agnostique de la technologie cible.
+
+  * La **simulation temporelle**  simule le comportement dans le temps du modèle structurel. Elle est réalisée après l’étape de synthèse de façon à s’assurer, d’une part, que l’opération de synthèse n’a pas altéré les fonctionnalités du système, et d’autre part, que l’introduction des délais dans les portes et les interconnections n’introduit pas d’erreur. La simulation temporelle est donc dépendante de la technologie cible. Pour réaliser une simulation temporelle, il faut disposer de:
+      * //__La librairie des cellules standards__//  , qui contient les modèles de portes logiques utilisés par la synthèse, et qui sont instanciées dans la //netlist//.
+      * //__La netlist__//  , qui contient la description structurelle du système, composée d'un ensemble de cellules standards interconnectées.
+      * //__Le SDF__//  , qui contient les délais des portes logiques et des interconnections, associé à la //netlist//
+
+Dans le cadre de ce tutoriel, nous utiliserons le simulateur logique **Modelsim**  de //Mentor Graphics//  pour réaliser les simulations fonctionnelles et temporelles des systèmes d’intérêts. Ce document présente l’utilisation de //Modelsim//  à travers la simulation fonctionnelle et temporelle d’un compteur BCD. Les sections traitant des simulations temporelles supposent que vous disposez des //netlist//  post-synthèse et/ou post-implémentation. Pour les étapes de synthèse et de placement & routage du compteur référez-vous aux tutoriels associés.
+
+Le répertoire de travail associé à ce tutoriel se situe à l'emplacement ''~/Tutos/compteur/simulation/''. Vous trouverez le code source du compteur BCD ainsi que son banc d’essai à l’emplacement: ''~/Tutos/compteur/sources/''. Les dossiers de travail associés aux simulations comportementales, post-synthèses, et post- placement & routage se situent respectivement dans les sous-répertoires: ''beh'', ''syn'', et ''pnr''.
+
+===== Environnement de travail =====
+
+//Modelsim//  s’exécute sur les postes de travail Linux dans un environnement ''tcsh''. Il est préférable de lancer //Modelsim//  à partir de votre répertoire de travail. La configuration de votre environnement de travail consiste à définir des variables d’environnement qui contiennent les chemins des exécutables et la hiérarchie du projet. Cette opération est réalisée par le script ''setup.csh''.
+
+==== Démarrer l’outil ====
+
+  * Se placer a la racine du projet et configurer l'environnement
+
+<code:bash>
+[shell]% cd ~/Tutos/compteur/
+[shell]% source setup.csh
+</code>
+
+  * Se placer dans le repertoire de travail et demarrer //Modelsim//
+
+<code:bash>
+[shell]% cd simulation/
+[shell]% vsim &
+</code>
+
+Une fois que //Modelsim//  est lancé, vous devriez voir apparaitre la fenêtre représentée à la <imgref fig:vsim>. Vous avez le choix de réaliser vos simulations via les menus de l’interface graphique, ou via l’interpréteur de cmmandes. Chaque opération réalisée via les menus possède une commande équivalente dans l'interpréteur. Vous pouvez donc noter chaque commande exécutée dans la console à la suite d’une opération réalisée via les menus, afin d’automatiser la procédure à l’aide d’un script.
+
+<imgcaption fig:vsim| Aperçus de la fenêtre principale de Modelsim>
+{{1_vsim.png?nolink&|Aperçus de la fenêtre principale de Modelsim}}
+</imgcaption>
+
+==== Obtenir de l’aide ====
+
+En complément de ce guide, vous pouvez obtenir de l’aide directement à partir de //Modelsim//. Pour connaître le détail d’une commande vous pouvez invoquer la commande dans l’interpréteur, suivi de la commande d’intérêt. Pour commencer, lisez l’aide de l’aide:
+
+<code:tcl>
+[modelsim]% help help
+</code>
+
+Vous avez également accès à l’intégralité de la documentation de //Modelsim//  via le menu //help//. Avant d’ouvrir l’aide, vous devez d’abord configurer le lecteur PDF à utiliser. Pour ce faire, sélectionnez ''Tools → Viewer Preference → PDF viewer'', puis remplissez le champs avec: ''evince''. Vous pouvez ouvrir l’aide en sélectionnant: ''Help → SE Documentation - PDF Bookcase''. Le PDF qui s’ouvre vous donne accès aux liens de la documentation de //Modelsim//, comme le montre la <imgref fig:help>.
+
+<imgcaption fig:help| Documentation de Modelsim>
+{{1_help.png?nolink&|Documentation de Modelsim}}
+</imgcaption>
+
+===== Simulations =====
+
+Dans cette partie, nous allons détailler la procédure permettant de réaliser des simulations fonctionnelles et temporelles avec //Modelsim//  à partir du compteur BCD. Afin de vérifier que le module ''compteur.vhd''  fonctionne correctement - c’est-à-dire compte de 0 à 9, s’incrémente à chaque coup d’horloge, et revient à zéro une fois la valeur maximale atteinte - nous allons évaluer son comportement à partir de son banc d’essai (''compteur_tb.vhd''). Pour toute question concernant le rôle du banc d’essai ou le VHDL référez-vous au matériel de cours sur le VHDL. Ici, nous présentons //Modelsim//  sous deux aspects: via l’interface graphique, et via l’interpréteur de commandes. Des modèles de scripts écrit en langage [[http://wiki.tcl.tk/|tcl]] (//tool command line//) sont donnés à la fin de cette partie pour automatiser les procédures.
+
+==== Simulation Fonctionnelle ====
+
+Créez un nouveau projet: ''File → new → project''  et complétez le répertoire de simulation:''~/Tutos/compteur/simulation/beh''. Puis, sélectionnez le fichier d’initialisation de //Modelsim//: ''/CMC/kits/AMSKIT616\_GPDK/simlib/modelsim.ini'', comme le montre la <imgref fig:newproj>. Après avoir validé, une nouvelle fenêtre va apparaitre, dans laquelle vous aurez le choix d’ajouter des fichiers. Sélectionnez ''Add existing Files → Browse'', puis sélectionnez les deux fichiers VHDL ''compteur.vhd''  et ''compteur_tb.vhd''.
+
+<imgcaption fig:newproj| Nouveau Projet>
+{{1_newproj.png?nolink&|Nouveau Projet}}
+</imgcaption><imgcaption fig:startsimbeh| Lancement de la simulation>
+{{1_startsimbeh.png?nolink&|Lancement de la simulation}}
+</imgcaption>
+
+Avant de lancer la compilation, il faut spécifier que le banc d’essai utilise la norme VHDL-2008. Sélectionnez le banc d’essai: ''click-droit → Properties → VHDL → Use 1076-2008''. Puis, pour lancer la compilation sélectionnez: ''compile → compile all''. Notez que vous pouvez double-cliquer sur une erreur pour afficher le détail. Finalement, si votre code compile sans erreurs, vous pouvez lancer la simulation en sélectionnant: ''simulation → start simulation''. Sélectionnez le banc d’essai comme le montre la<imgref fig:startsimbeh> et choisissez ''Resolution → ps''.
+
+Alternativement, vous pouvez utiliser l’interface en ligne de commande pour simuler le système:
+
+  * Création de la librairie de travail:
+
+<code:tcl>
+[modelsim]% vlib beh/work
+</code>
+
+  * Compilation du compteur et de son banc d’essai:
+
+<code:tcl>
+[modelsim]% vcom -work beh/work ../sources/hdl/compteur.vhd
+[modelsim]% vcom -2008 -work beh/work ../sources/hdl/compteur_tb.vhd
+</code>
+
+  * Lancement de la simulation:
+
+<code:tcl>
+[modelsim]% vsim -t ps work.compteur_tb
+</code>
+
+À ce stade, une nouvelle fenêtre de //Modelsim//  s’ouvre. Remarquez que le prompt est devenu ''vsim>'', ce qui signifie que vous êtes en mode simulation. Pour quitter ce mode, faites: ''simulation → end simulation''. Alternativement, vous pouvez utiliser l’interface en ligne de commande pour quitter la simulation avec la commande ''quit'':
+
+<code:tcl>
+[vsim]% quit -sim
+</code>
+
+Pour visualiser les signaux vous devez dans un premier temps les ajouter au chronogramme, puis lancer la simulation pour un temps donné. Dans la fenêtre ''objects'', sélectionnez les signaux que vous souhaitez voir apparaitre sur votre chronogramme et faites: ''click-droit → Add-to → Waves → selected signals''. Choisissez ensuite le temps que vous souhaitez simuler, disons 40ns, puis cliquez sur le bouton ''run''. Alternativement, vous pouvez utiliser l’interface en ligne de commande pour lancer la simulation:
+
+<code:tcl>
+[vsim]% run 40 ns
+</code>
+
+<imgcaption fig:simubeh| Simulation comportementale du compteur>
+{{1_simubeh.png?nolink&|Simulation comportementale du compteur}}
+</imgcaption>
+
+==== Simulation Temporelle ====
+
+Cette section détaille la procédure à suivre pour réaliser la simulation temporelle //netlist//  du compteur. Cette procédure est valable pour toute //netlist//  basée sur la technologie ''gpdk45''.
+
+<imgcaption fig:newprojrtl| Nouveau Projet>
+{{1_newproj_rtl.png?nolink&|Nouveau Projet}}
+</imgcaption><imgcaption fig:lib| Librairies>
+{{1_gsclib.png?nolink&|Librairies}}
+</imgcaption><imgcaption fig:sdf| SDF>
+{{1_sdf.png?nolink&|SDF}}
+</imgcaption>
+
+Créez un nouveau projet: ''File → new → project'', puis complétez le répertoire de simulation: ''~/Tutos/compteur/simulation/syn'' comme le montre la <imgref fig:newprojrtl>. Puis, ajoutez la //netlist//  (''compteur_net.v''), ainsi que le banc d’essai (''compteur_tb.vhd'').
+
+Avant de lancer la compilation, spécifiez que le banc d’essai utilise la norme VHDL-2008: ''click-droit → Properties → VHDL → Use 1076-2008''. Puis, lancez la compilation: ''compile → compile all''. Finalement, si votre code compile sans erreurs, lancez la simulation: ''simulation → start simulation''. Dans la fenêtre qui s’ouvre nous allons configurer 3 onglets:
+
+  * //Design//: Sélectionnez: ''work/compteur_tb'', puis: ''Resolution → ps''.
+  * //Libraries//: Sélectionnez: ''Add'', puis cherchez la librairie des cellules standards comme le montre la <imgref fig:lib>: ''/CMC/kits/AMSKIT616_GPDK/simlib/gsclib045_ver''.
+  * //SDF//: Sélectionnez ''Add'', puis cherchez le fichier SDF correspondant à la //netlist//  comme le montre la <imgref fig:sdf> (//notez que ces deux fichiers doivent avoir le même nom//): ''$~/Tutos/compteur/implementation/syn/netlist/compteur.syn.sdf''. Dans la partie ''Apply to region'', indiquez à quelle partie du système le fichier SDF doit être appliqué. C’est-à-dire, donnez le nom de l’instance de dans le banc d’essai, soit ici:  ''dut''. Le fichier SDF contient trois types de délais: //min, typical//, et //max//. Sélectionnez  ''max''.
+Alternativement, vous pouvez utiliser l’interface en ligne de commande pour simuler le système:
+
+  * Création de la librairie de travail:
+  
+<code:tcl>
+[modelsim]% vlib syn/work
+</code>
+
+  * Compilation de la //netlist//  et de son banc d’essai:
+
+<code:tcl>
+[modelsim]% vlog -work rtl/work ../implementation/syn/netlist/compteur.syn.v
+[modelsim]% vcom -2008 -work rtl/work ../sources/hdl/compteur_tb.vhd
+</code>
+
+  * Démarrage de la simulation avec le fichier SDF et la librairie des cellules standards:
+
+<code:tcl>
+[modelsim]% vsim -t ps -sdfmax dut=../implementation/syn/netlist/compteur.syn.sdf \
+                 -L /CMC/kits/AMSKIT616_GPDK/simlib/gsclib045_ver work.compteur_tb
+</code>
+
+  * Lancement de la simulation
+
+<code:tcl>
+[vsim]% run -all
+</code>
+
+En effectuant un zoom (raccourcis clavier  ''c'', ou bouton  ''+''), vous devriez voir un délai entre le front montant de l’horloge et l’établissement du signal de sortie, comme le montre la <imgref fig:simupnr>.
+
+<imgcaption fig:simupnr| Simulation temporelle du compteur>
+{{1_simupnr.png?nolink&|Simulation temporelle du compteur}}
+</imgcaption>
+
+==== Enregistrement de l’activité ====
+
+L’activité générée par la simulation d’un circuit peut être enregistrée dans un fichier au format  ''vcd'' (//Value Change Dump//). Un fichier VCD contient des informations sur les changements de valeurs des signaux du circuit au cours de sa simulation. L’activité du circuit (les //stimuli//) est contrôlée par le banc d’essai, tandis que la durée de simulation est réglée dans le simulateur. Cette étape sera notamment utile pour réaliser une analyse dynamique de la consommation d’énergie du compteur, après synthèse et/ou placement & routage. L’enregistrement de l’activité de simulation est une étape supplémentaire qui doit se dérouler entre le démarrage de la simulation ( ''vsim'') et son lancement ( ''run''). Ici on considère la simulation de la //netlist//  post-implémentation. La procédure se déroule comme suit:
+
+  * Création du fichier  ''vcd'' (après avoir démarré la simulation avec  ''vsim''):
+<code:tcl>
+[vsim]% vcd file syn/compteur.syn.vcd
+</code>
+
+  * Ajout des signaux à enregistrer (ici on enregistre tous les signaux):
+
+<code:tcl>
+[vsim]% vcd add /compteur_tb/dut/*
+</code>
+
+  * Lancement de la simulation
+
+<code:tcl>
+[vsim]% run -all
+</code>
+
+  * Enregistrement de l’activité dans le fichier :
+
+<code:tcl>
+[vsim]% vcd flush
+</code>
+
+==== Modèles de script ====
+
+//Modelsim//  est un outil qui se contrôle principalement en ligne de commande à partir de son interpréteur. Comme on l’a vu, seule une sous partie des options de //Modelsim//  est accessible via les menus de l’interface graphique. L’interpréteur de //Modelsim//  comprend le langage //tcl//  et contient des commandes spécifiques ( ''vcom'',  ''vsim'', etc.). Ceci permet d’utiliser des scripts pour compiler et simuler un système. C’est la méthode privilégiée pour travailler en équipe car il est préférable de partager un script, plutôt qu’une procédure détaillant toutes les options à utiliser pour simuler correctement un système. Pour exécuter le script dans l’interpréteur de //Modelsim//  faites:
+
+<code:tcl>
+[modelsim]% source <script.tcl>
+</code>
+
+Le script présenté ci-dessous est un modèle que vous pouvez réutiliser pour réaliser n’importe quelle simulation comportementale mettant en oeuvre plusieurs fichiers VHDL.
+
+<code:tcl sim_beh.tcl>
+# Fichier     : sim_beh.tcl
+# Description : Compilation et simulation comportementale
+# --------------------------------------------------------
+set work    "path/to/work"
+set srcD    "path/to/vhdl/sources"
+set top     "top-name"
+set tb      "${top}_tb"
+set modules [list "module-1" "module-2" "module-N"]
+
+# Mise à jour de la librairie de travail
+if { [file exists $work] } {
+    vdel -all -lib $work
+}
+vlib $work
+
+# Compilation
+foreach module $modules {
+    vcom -2008 -work $work $srcD/$module.vhd
+}
+vcom -2008 -work $work $srcD/$top.vhd
+vcom -2008 -work $work $srcD/$tb.vhd
+
+# Simulation
+vsim $work.$tb
+
+# Exécution
+do ${top}_wave.do
+run -all
+</code>
+
+Le script présenté ci-dessous est un modèle que vous pouvez réutiliser pour réaliser n’importe quelle simulation temporelle mettant en oeuvre une //netlist//  et son fichier  ''sdf'' associé:
+
+<code:tcl sim_syn.tcl>
+# Fichier     : sim_syn.tcl
+# Description : Compilation et simulation temporelle
+# ------------------------------------------------------------
+set work    "path/to/work"
+set srcD    "path/to/vhdl/sources"
+set top     "top-name"
+set tb      "${top}_tb"
+set net     "path/to/netlist/${top}.syn.v"
+set sdf     "path/to/netlist/${top}.syn.sdf"
+set vcd     "${top}.syn.vcd"
+set netLib  "/CMC/kits/AMSKIT616_GPDK/simlib/gsclib045_ver"
+set dut     "dut"
+
+# Mise à jour de la librairie de travail
+if { [file exists $work] } {
+    vdel -all -lib $work
+}
+vlib $work
+
+# Compilation
+vlog -work $work $net
+vcom -2008 -work $work $srcD/$tb.vhd
+
+# Simulation
+vsim -L $netLib -t ps -sdfmax $dut=$sdf $work.$tb
+
+# Enregistrement de l'activité au format VCD
+vcd file $vcd
+vcd add /$tb/$dut/*
+
+# Exécution
+do ${top}_wave.do
+run -all
+vcd flush
+</code>
+
+===== Analyser et exporter ses résultats =====
+
+Dans cette partie nous allons nous intéresser aux moyens permettant de configurer l’environnement graphique de //Modelsim//, à la configuration des signaux dans les chronogrammes, ainsi qu’à la procédure permettant d’exporter les chronogrammes de simulation de façon appropriée pour des rapports.
+
+==== Configurer les chronogrammes ====
+
+Lorsque vous simulez un système avec //Modelsim//, que ce soit en simulation comportementale ou en simulation temporelle, les signaux que vous voyez par défaut dans la catégorie  ''objects'' sont ceux du banc d’essai. Vous pouvez accéder à d’autres signaux dans la hiérarchie de votre système, en navigant dans la catégorie  ''sim - Default'' tel que le montre la <imgref fig:sighier>.
+
+Par défaut, la fenêtre des chronogrammes de //Modelsim//  se présente avec un fond noir et des courbes vertes, et le format des signaux est en général hexadécimal. Cependant, à partir d’un certain nombre de signaux à l’écran il devient difficile de tous les discerner. Pour modifier le format, la couleur ou le nom affiché d’un signal, sélectionnez un signal, ou un groupe de signaux, et faites  ''click-droit → properties''. Vous obtiendrez la fenêtre de la <imgref fig:format> à partir de laquelle vous pouvez modifier les propriétés qui vous intéressent.
+
+Il est possible de sauvegarder la configuration du chronogramme de façon à pouvoir la réutiliser. Placez le curseur n’importe où sur le chronogramme et faites  ''{File → Save Format}''. Le fichier dans lequel vous sauvegardez le format possède l’extension  ''.do'' et peut être réutilisé entre l’étape  ''vsim'' et l’étape  ''run'' avec la commande:  ''do''.
+
+<imgcaption fig:sighier| Hiérarchie des signaux>
+{{1_sighier.png?nolink&|Hiérarchie des signaux}}
+</imgcaption><imgcaption fig:format| Format des signaux>
+{{1_format.png?nolink&|Format des signaux}}
+</imgcaption>
+
+==== Exporter les chronogrammes ====
+
+Une fois que vous avez terminé une simulation, que vous avez ajouté les signaux d’intérêts de la hiérarchie, et que vous les avez configurés de sorte qu’ils possèdent le bon format et des couleurs appropriées pour les distinguer, vous pouvez exporter une image de votre chronogramme pour l’insérer dans un rapport. Vous avez toujours le choix d’utiliser une capture d’écran, mais pour un résultat plus clair, suivez la procédure suivante:
+
+  * D’abord, réglez le zoom de votre chronogramme en utilisant les boutons appropriés, ou bien, après avoir positionné le curseur dans le chronogramme sur la zone d’intérêt, en utilisant les touches  ''c'' (zoom) et  ''o'' (dézoom) de votre clavier.
+
+  * Ensuite, en suivant:  ''File → Print Postscript'', vous obtiendrez une fenêtre permettant d’exporter le chronogramme au format postscript. Les configurations relatives au chronogramme sont disponibles dans la fenêtre:  ''Write postscript'', et les configurations relatives à la page elle-même sont disponibles dans la fenêtre:  ''Page setup'' (en cliquant sur  ''setup''). Vous avez différentes options, pour commencer utilisez la configuration de la <imgref fig:ps> et de la <imgref fig:pssetup>.
+
+  * Enfin, pour convertir l’image au format  ''ps'' en image au format  ''png'', utilisez la commande  ''convert''. Vous pouvez aussi utiliser //Inkscape//  pour créer et modifier un fichier  ''svg''.
+
+<code:bash>
+[shell]% convert -density 150 -geometry 100% <file.ps> <file.png>
+</code>
+
+<imgcaption fig:ps| Configuration>
+{{1_ps.png?nolink&|Configuration}}
+</imgcaption><imgcaption fig:pssetup| Propriétés>
+{{1_pssetup.png?nolink&|Propriétés}}
+</imgcaption>
diff --git a/doc/wiki/2_synthese.dwiki b/doc/wiki/2_synthese.dwiki
new file mode 100644
index 0000000000000000000000000000000000000000..1842ba57a334839c9eb22620f73df9dfb3ca4b45
--- /dev/null
+++ b/doc/wiki/2_synthese.dwiki
@@ -0,0 +1,258 @@
+
+====== Synthèse des circuits intégrés numériques ======
+
+— //[[mickael.fiorentino@polymtl.ca|Mickael Fiorentino]] 2019/07/10// —
+
+La synthèse logique est une opération qui transforme le //modèle comportemental// d’un système numérique décrit à haut niveau en un //modèle structurel//, ou //netlist//, composé de portes logiques élémentaires interconnectées. Le plus souvent la //netlist// est décrite en verilog. L’ensemble des portes logiques élémentaires utilisées pendant la synthèse sont fournies dans une **librairie de cellules standards** (//standard cells//). Ces librairies sont généralement fournies par les fabricants de circuits intégrés, tels que TSMC, Intel, ou STMicroelectronics, qui réalisent des cellules standards pour chaque nouvelle technologie de transistor (90nm, 45nm, 28nm FD-SOI etc.). Les cellules standards sont un ensemble de circuits élémentaires (NAND, NOT, NOR... et cellules complexes) réalisées au niveau physique (dessin des masques). Un ensemble de modèles (logiques, physiques, délais) sont extraits à partir des simulations des cellules standards, et composent le **kit** de conception associé à une technologie. L'outil de synthèse utilise ces modèles pour concevoir une //netlist//.
+
+Plusieurs outils de synthèse sont utilisés dans l’industrie. Pour la conception ASIC, les principaux outils de synthèse sont //Design Vision// de //Synopsys// et //Genus// de //Cadence//. Dans le cadre de ces tutoriels nous utiliserons l’environnement de //Cadence//, mais il est important de garder à l’esprit que le flot de conception est sensiblement le même avec //Synopsys//. Quel que soit l’outil de synthèse utilisé, les étapes pour synthétiser un modèle comportemental sont toujours les mêmes:
+
+  * **Lecture**: L’outil lit le ou les fichiers HDL qui décrivent le modèle comportemental du système, et analyse leur contenu. Si des erreurs de syntaxe sont présentes l’outil retourne une erreur.
+
+  * **Élaboration**: L’outil construit un premier modèle matériel du système à partir de portes logiques génériques, qui ne sont pas issues d’une librairie particulière. À cette étape, l’outil effectue quelques optimisations, en particulier, il transforme les machines à états en circuits séquentiels.
+  
+  * **Synthèse**: À partir du résultat de l’étape précédente, l’outil remplace chaque porte logique générique par son équivalent dans la librairie spécifiée. Il effectue des optimisations plus poussées qui dépendent du type de cellules standard disponibles dans la librairie. Ici, nous utiliserons la librairie standard  de Cadence.
+
+Ce document présente l’utilisation de l’outil de synthèse //**Genus**//, à travers l’exemple du compteur BCD. Le répertoire de travail associé à ce guide se situe à l'emplacement ''~/Tutos/compteur/implementation/syn''. Le code source du compteur se trouve à l’emplacement: ''~/Tutos/compteur/sources/''.
+
+===== Environnement de travail =====
+
+//Genus// s’exécute sur les postes de travail Linux dans un environnement ''tcsh''. L’initialisation de l’environnement de travail s’effectue à partir du fichier de configuration ''setup.csh''. Avant de lancer //Genus//, vous devez vous placer dans votre répertoire de travail.
+
+==== Démarrer l’outil ====
+
+  * Se placer a la racine du projet et configurer l'environnement
+
+<code:bash>  
+[shell]% cd ~/Tutos/compteur/
+[shell]% source setup.csh
+</code>
+
+  * Se placer dans le repertoire de travail et démarrer //Genus//
+  
+<code:bash>
+[shell]% cd implementation/syn/
+[shell]% genus &
+</code>
+
+//Genus// est un outil qui se contrôle principalement en ligne de commande. Notez que vous pouvez afficher et masquer l’interface graphique de //Genus// à partir des commandes ''gui_show''  et ''gui_hide''. Vous pouvez visualiser l’effet de chaque étape de synthèse dans le GUI en ouvrant l’onglet ''schematic''. Lorsque vous fermez l’interface graphique choisissez l’option ''Hide GUI''. Après avoir lancé //Genus//, le prompt de votre terminal devient l’interpréteur de //Genus//:
+
+<code:tcl>
+genus@root>
+</code>
+
+==== Obtenir de l’aide ====
+
+En complément de ce guide, vous pouvez obtenir de l’aide directement à partir de //Genus//. Pour connaître le détail d’une commande vous pouvez invoquer la commande ''help'' et la commande ''man'' dans l’interpréteur, suivi de la commande ou de l’attribut d’intérêt. Notez que la commande ''help'' reconnait l’astérisque ''*'', ce qui est très utile lorsqu’on cherche un groupe de commandes. Pour commencer, lisez l’aide sur les aides:
+
+<code:tcl>
+[genus]% help help*
+[genus]% man help
+</code>
+
+Vous avez également accès à l’intégralité de la documentation de //Genus// à partir de l’aide //Cadence//. Pour lancer l’aide //Cadence// et accéder à toute la documentation, utilisez la commande ''genus_help''. Vous pouvez naviguer dans l’aide en parcourant les différents dossier, comme le montre la <imgref fig:cdnshelp>.
+
+<imgcaption fig:cdnshelp| Documentation de Genus>
+{{2_help.png|Documentation de Genus}}
+</imgcaption>
+
+===== Flot de conception =====
+
+Cette partie détaille un flot de conception simple permettant de réaliser la synthèse logique d’un système matériel avec //Genus//. Ce flot utilise la technologie éducative ''GPDK45'' de //Cadence// (45nm), et utilise le compteur BCD comme exemple.
+
+==== Configuration ====
+
+Quelques configurations sont nécessaires avant de procéder à la synthèse du système. //Genus// se configure en modifiant la valeur de ses variables internes, appelés //attributs//. Pour modifier la valeur d’un attribut, utilisez la commande ''set_db''. Notez que vous pouvez faire référence à une variable d’environnement de Linux dans //Genus// en utilisant: ''$::env(<var>)''. Dans un premier temps, nous allons configurer la verbosité, la norme VHDL à utiliser et l’emplacement du répertoire contenant le code source du compteur. Ces configurations sont optionnelles, mais très utiles.
+
+
+  * Définir le niveau de verbosité (réglable entre 1 et 11):
+
+<code:tcl>
+[genus]% set_db / .information_level 9
+</code>
+
+  * Configurer l’outil pour qu’il utilise la norme VHDL-2008:
+
+<code:tcl>
+[genus]% set_db / .hdl_vhdl_read_version 2008
+</code>
+
+  * Définir l’emplacement du répertoire contenant le code source:
+
+<code:tcl>
+[genus]% set_db / .init_hdl_search_path $::env(SRC_DIR)
+</code>
+
+Dans un second temps, nous allons charger les librairies de la technologie ''GPDK45''. Notez qu’il est indispensable de configurer les librairies pour effectuer la synthèse du système.
+
+  * Définir l’emplacement des librairies:
+
+<code:tcl>
+[genus]% set_db / .init_lib_search_path [list $::env(FE_TIM_LIB) $::env(BE_QRC_LIB) $::env(BE_LEF_LIB)]
+</code>
+
+  * **LIB**: Les fichiers ''.lib'' contiennent les informations relatives aux délais des cellules standards.
+
+<code:tcl>
+[genus]% read_libs fast_vdd1v0_basicCells.lib
+</code>
+
+  * **LEF**: Les fichiers ''.lef'' contiennent les informations physiques des cellules standards.
+
+<code:tcl>
+[genus]% read_physical -lef gsclib045_tech.lef
+</code>
+
+  * **QRC**: Les fichiers ''.qrc'' contiennent les informations physiques des interconnections.
+
+<code:tcl>
+[genus]% read_qrc gpdk045.tch
+</code>
+
+==== Élaboration ====
+
+L’élaboration du système est précédé de la compilation du modèle VHDL. Une fois que le système est élaboré, il est faut vérifier qu’aucun élément du système n’est manquant.
+
+  * Compiler le code source VHDL du compteur:
+
+<code:tcl>
+[genus]% read_hdl -vhdl compteur.vhd
+</code>
+
+  * Élaborer le système. //Note: vous devez utiliser le nom du top-level// (ici ''compteur'').
+
+<code:tcl>
+[genus]% elaborate compteur
+</code>
+
+  * Vérifier qu'aucun élément du système n'est manquant.
+
+<code:tcl>
+[genus]% check_design -unresolved
+</code>
+
+==== Contraintes ====
+
+On appelle //contraintes// l’ensemble des spécifications du système, telles que la fréquence d’horloge, la surface, ou le budget énergétique. La spécification des contraintes donne à l’outil des objectifs à atteindre à travers le processus de synthèse. Ces objectifs sont ensuite vérifiés par des analyses post-synthèse. Par exemple, connaissant les délais des portes logiques et des interconnections dans le circuit (information issue des librairies), ainsi que la contrainte sur la fréquence d’horloge, l’outil de synthèse peut optimiser le circuit de façon à ce qu’il atteigne les performances visées. Les contraintes sont spécifiées dans un fichier ''.sdc'', avec un formalisme basé sur le langage //tcl//. L'exemple ci-dessous montre les contraintes temporelles du compteur BCD:
+
+<code:tcl>
+# Fichier    : timing.sdc
+# Description: Contraintes temporelles du compteur
+# ------------------------------------------------
+
+# Configuration
+set_time_unit -picoseconds
+set_load_unit -femtofarads
+set_db / .operating_conditions PVT_1P1V_0C
+
+# Horloge principale: 1GHz
+set clk "clk"
+create_clock -period 1000 -name $clk [get_ports i_clk]
+
+# Marges: setup = 100ps, hold = 30ps 
+set_db [get_clocks $clk] .clock_setup_uncertainty 100
+set_db [get_clocks $clk] .clock_hold_uncertainty  30
+
+# Entrees
+set_input_delay 300 -clock [get_clocks $clk] [all_inputs]
+set_db [all_inputs] .external_driver [vfind [vfind / -libcell BUFX20] -libpin Y]
+
+# Sorties
+set_output_delay 300 -clock [get_clocks $clk] [all_outputs]
+set_db [all_outputs] .external_pin_cap 1000
+</code>
+
+Après avoir conçus le fichier de contraintes il faut le charger dans //Genus//, puis vérifier que les contraintes sont complètes et ont été correctement appliquées.
+
+  * Appliquer les contraintes:
+
+<code:tcl>
+[genus]% read_sdc $::env(CONST_DIR)/timing.sdc
+</code>
+
+  * Vérifier les contraintes temporelles:
+
+<code:tcl>
+[genus]% report_timing -lint > $::env(SYN_REP_DIR)/compteur.timing_lint.rpt
+</code>
+
+==== Synthèse ====
+
+Le processus de synthèse, qui intervient après l’élaboration du système et l’application des contraintes, se décompose en trois étapes: synthèse générique, association des cellules standards, et optimisations.
+
+La synthèse générique consiste à transformer le système en un ensemble de portes logiques génériques. À ce stade la hiérarchie du système et les noms des instances sont conservés. Il est possible d’aplanir (//ungroup//) la hiérarchie, de façon à faciliter les optimisations réalisées par l’outil. La seconde étape de synthèse consiste à associer les cellules standards de la technologie aux portes logiques de la technologie, et réaliser un premier ensemble d’optimisations. La dernière étape consiste à appliquer des optimisations plus poussées, durant lesquelles l’algorithme de synthèse tente de faire correspondre les performances du système avec les contraintes.
+
+Notez qu’il est possible de contrôler l’effort avec lequel chacune des trois étapes de synthèse est réalisées en modifiant la valeur (''high'', ''medium'', ''low'', ''express'', et ''none'') des attributs associés. Il s’agit d’un compromis entre rapidité et efficacité des étapes de synthèse.
+
+Finalement, on vous suggère de générer une //netlist// intermédiaire après chaque étape de synthèse pour pouvoir observer leurs effets sur le système.
+
+
+  * Synthèse générique:
+
+<code:tcl>
+[genus]% set_db / .syn_generic_effort high
+[genus]% ungroup -all -simple  
+[genus]% syn_generic compteur
+[genus]% write_hdl > $::env(SYN_NET_DIR)/compteur.syn_gen.v  
+</code>
+
+  * Association des cellules standards:
+
+<code:tcl>
+[genus]% set_db / .syn_map_effort high
+[genus]% syn_map compteur
+[genus]% write_hdl > $::env(SYN_NET_DIR)/compteur.syn_map.v    
+</code>
+
+  * Optimisations du système:
+ 
+<code:tcl>
+[genus]% set_db / .syn_opt_effort high
+[genus]% syn_opt compteur
+[genus]% write_hdl > $::env(SYN_NET_DIR)/compteur.syn_opt.v    
+</code>
+
+
+==== Netlist ====
+
+Une fois votre système synthétisé, vous pouvez l’exporter sous la forme d’une //netlist//; c’est-à-dire une représentation structurelle du système en verilog qui instancie les cellules standards de la librairie. Cette //netlist// servira de base pour la simulation post-synthèse et le placement & routage. Pour la simulation post-synthèse, la //netlist// doit être associée à un fichier SDF qui contient l’ensemble des délais des portes logiques et des interconnections.
+
+  * Produire la //netlist// en verilog.
+
+<code:tcl>
+[genus]% write_hdl > $::env(SYN_NET_DIR)/compteur.syn.v
+</code>
+
+  * Produire le fichier SDF associé:
+
+<code:tcl>
+[genus]% write_sdf > $::env(SYN_NET_NET)/compteur.syn.sdf
+</code>
+
+==== Rapports ====
+
+Cette partie présente les commandes permettant d’analyser les résultats de synthèse du système (analyse temporelle, surface occupée, puissance consommée). L’analyse temporelle statique (//Static Timing Analysis (STA)//) permet d’évaluer si le système synthétisé rencontre les contraintes temporelles. Le rapport de surface permet d’évaluer l’aire occupée par le système, et le rapport de portes logiques liste les cellules standards utilisées. Enfin, le rapport de puissance donne une évaluation sommaire de la puissance consommée, compte tenu des propriétés de la technologie, et d’une évaluation de l’activité basée sur la fréquence d’opération du système. Notez que la consommation d'énergie du système est estimée avec plus de détail dans la partie [[tutos:compteur:puissance|analyse de puissance]].
+
+  * Générer un rapport d’analyse temporelle statique:
+
+<code:tcl>
+[genus]% report_timing > $::env(SYN_REP_DIR)/compteur.syn.timing.rpt
+</code>
+
+  * Générer un rapport de surface:
+
+<code:tcl>
+[genus]% report_area > $::env(SYN_REP_DIR)/compteur.syn.area.rpt
+</code>
+
+  * Générer un rapport du nombre de portes logiques utilisées:
+
+<code:tcl>
+[genus]% report_gates > $::env(SYN_REP_DIR)/compteur.syn.gates.rpt
+</code>
+
+  * Générer un rapport de puissance:
+
+<code:tcl>
+[genus]% report_power > $::env(SYN_REP_DIR)/compteur.syn.power.rpt
+</code>
diff --git a/doc/wiki/3_implementation.dwiki b/doc/wiki/3_implementation.dwiki
new file mode 100644
index 0000000000000000000000000000000000000000..9c54dca3b3e88b3d77e7779888dfb262455855fb
--- /dev/null
+++ b/doc/wiki/3_implementation.dwiki
@@ -0,0 +1,366 @@
+
+====== Placement et routage des circuits intégrés numériques ======
+
+— //[[mickael.fiorentino@polymtl.ca|Mickael Fiorentino]] 2019/07/10// —
+
+Les étapes de placement & routage (PnR) d'un circuit intégré numérique interviennent post-synthèse dans le flot de conception. Ce tutoriel utilise un approche simple, qui vous permettra d’apprécier les principales étapes nécessaires à la conception d’un circuit intégré, mais ne constitue en rien un guide complet et exhaustif. Notez qu’à la fin de ce tutoriel votre circuit ne sera pas prêt à partir en fabrication; les dernières étapes pour obtenir un circuit complet ne seront pas abordées.
+
+Ce document présente l’utilisation de l’outil de synthèse //**Innovus**// de //Cadence//, à travers l’exemple du compteur BCD. À partir de la //netlist// post-synthèse, et des librairies de la technologie ''GPDK45'', ce tutoriel vous guidera jusqu’à l’obtention du dessin des masques de votre circuit en parcourant les étapes suivantes:
+
+  - **Partitionnement**: Cette étape consiste à déterminer la taille et la forme du circuit à partir des informations de la //netlist// et de la technologie. L’emplacement des différents modules du système, ainsi que la position des alimentations et des pins du circuit, sont choisis également à cette étape.  
+  - **Placement**: Cette étape consiste à placer les cellules standards du circuit en tenant compte du partitionnement réalisé à l’étape précédente, mais également des contraintes du système.  
+  - **Synthèse de l’arbre d’horloge**: Cette étape permet de constituer les réseaux d’horloges à travers les éléments séquentiels du circuit. Les propriétés de l’arbre d’horloge ont des conséquences directes sur les performances du circuit.  
+  - **Routage**: Cette étape consiste à effectuer le routage automatique des cellules standards du circuit, en tenant compte des contraintes du système.
+  - **Vérifications**: Les principales étapes de vérification sont le STA (//Static Timing Analysis//) qui garanti le bon fonctionnement du circuit vis-à-vis de ses contraintes temporelles. le DRC (//Design Rule Check//), qui valide le respect des règles de conception liées à la technologie, et le LVS (//Layout Versus Schematic//) qui vérifie que le circuit final (post-PnR) est électriquement identique au circuit original (post-synthèse).
+
+Cette procédure débute en supposant que vous avez suivi le tutoriel sur la [[tutos:compteur:synthese|synthèse]], et que vous possédez une //netlist// du compteur BCD synthétisée avec la technologie ''GPDK45''. Le répertoire de travail associé à ce guide se situe à l’adresse: ''~/Tutos/compteur/implementation/pnr''.
+
+===== Environnement de travail =====
+
+==== Démarrer l’outil ====
+
+//Innovus// s’exécute sur les postes de travail Linux dans un environnement ''tcsh''. L’initialisation de l’environnement de travail s’effectue à partir du fichiers de configuration ''setup.csh''. Avant de lancer //Innovus//, vous devez vous placer dans votre répertoire de travail, et vérifier que le fichier ''cds.lib'' est bien présent. Ce fichier contient les chemins vers les librairies de travail.
+
+  * Se placer a la racine du projet et configurer l'environnement
+
+<code:bash>
+[shell]% cd ~/Tutos/compteur
+[shell]% source setup.csh
+</code>
+
+  * Se placer dans le repertoire de travail et demarrer l'outil Innovus
+  
+<code:bash>
+[shell]% cd implementation/pnr
+[shell]% innovus
+</code>
+
+Notez qu’//Innovus// est un outil qui se contrôle avec l’interface graphique en complément de l’interface en ligne de commande. L’édition manuelle du dessin des masques ne peut se faire qu’à partir de l’interface graphique. En revanche, seule l’interface en ligne de commande fourni l’intégralité des fonctionnalités des différents outils. D’autre part, le contrôle des outils en ligne de commande permet d’automatiser et de reproduire un flot de conception à l’aide de scripts. Après avoir lancé //Innovus//, le prompt de votre terminal devient l’interpréteur d’//Innovus//:
+
+<code:tcl>
+[innovus]%
+</code>
+
+==== Obtenir de l’aide ====
+
+En complément de ce guide, vous pouvez obtenir de l’aide directement à partir d’//Innovus//. Pour connaître le détail d’une commande vous pouvez invoquer la commande ''help'' et la commande ''man'' dans l’interpréteur, suivi de la commande ou de l’attribut d’intérêt. Notez que la commande ''help'' reconnait l’astérisque ''*'', ce qui est très utile lorsqu’on cherche un groupe de commande. Pour commencer, lisez l’aide sur les aides:
+
+<code:tcl>
+[innovus]% help help*
+[innovus]% man help
+</code>
+
+Vous avez également accès à l’intégralité de la documentation d’//Innovus//, directement dans l’aide //Cadence//. Pour lancer l’aide //Cadence//, et accéder à toute la documentation, utilisez la commande ''innovus_help'' dans l’interpréteur. Vous pouvez naviguer dans l’aide en parcourant les différents dossier, et afficher leur contenu en double cliquant dessus, comme le montre la <imgref fig:cdnshelp>.
+
+<imgcaption fig:cdnshelp| Documentation d’Innovus>
+{{3_help.png?nolink|Documentation d’Innovus}}
+</imgcaption>
+
+===== Flot de conception =====
+
+==== Initialisation ====
+
+//Innovus// se configure en modifiant la valeur de ses variables internes. Pour modifier la valeur d’une variable, utilisez la commande ''set''. Notez que vous pouvez faire référence à une variable d’environnement de Linux dans //Innovus// en utilisant: ''$::env(<variable>)''.
+
+Dans un premier temps, nous allons configurer les libraires de référence de la technologie ''GPDK45''. Ici, contrairement à //Genus//, nous utiliserons les libraires //Open Access// (OA) de Cadence à la place des libraires LEF. Puis nous allons définir les informations sur le module à implémenter, c’est à dire l’emplacement de la //netlist// post-synthèse, le nom module le plus haut dans la hiérarchie (//top-level//), ainsi que l’alimentation:
+
+  * Initialisation des librairies OA (//Notez que les chemins des librairies utilisées ici sont définies dans le fichier ''cds.lib''//):
+
+<code:tcl>
+[innovus]% set init_oa_ref_lib [list gsclib045_tech gsclib045 gpdk045 giolib045]
+</code>
+
+  * Initialisation de la //netlist// et du //top-level//:
+
+<code:tcl>
+[innovus]% set init_verilog $::env(SYN_NET_DIR)/compteur.syn.v
+[innovus]% set init_design_settop 1
+[innovus]% set init_top_cell compteur  
+</code>
+
+  * Initialisation de l’alimentation:
+
+<code:tcl>
+[innovus]% set init_gnd_net VSS
+[innovus]% set init_pwr_net VDD
+</code>
+
+Dans un second temps, nous allons créer un fichier de configuration qui va définir les conditions d’opération du système. Ce type de configuration s’appelle //Multi-Mode Multi-Corner// (''mmmc'') dans //Innovus//.
+
+  * Définition du fichier contenant la configuration //Multi-Mode Multi-Corner//
+
+<code:tcl>
+[innovus]% set init_mmmc_file $::env(CONST_DIR)/mmmc.tcl
+</code>
+
+L'exemple suivant montre une configuration simple ''mmmc'' adaptée pour le compteur BCD. Son objectif est de définir les conditions d’opérations (//analysis view//) qui serviront de cible pour l’implémentation du système. Ces conditions sont créées à partir des contraintes post-synthèse et des conditions de timing, elles même dérivées de la librairie des capacités parasites et des librairies temporelles.
+
+<code:tcl mmmc.tcl>
+# Fichier     : mmmc.tcl
+# Description : Multi-Mode Multi-Corner
+# --------------------------------------
+
+# Librairie des cellules standards
+set fastlib $::env(FE_TIM_LIB)/fast_vdd1v0_basicCells.lib 
+create_op_cond -name pvt_fast -P 1.0 -V 1.0 -T 25.0 -library_file $fastlib
+create_library_set -name libs_fast -timing $fastlib -si $::env(BE_CDB_LIB)/fast.cdb
+
+# Librairie des interconnexions 
+create_rc_corner -name rc_basic -qx_tech_file $::env(BE_QRC_LIB)/gpdk045.tch
+create_delay_corner -name fast_basic -library_set libs_fast -rc_corner rc_basic
+
+# Conditions d'opérations
+create_constraint_mode -name const_mode -sdc_files $::env(CONST_DIR)/${DESIGN}.syn.sdc
+create_analysis_view -name av_fast -constraint_mode const_mode -delay_corner fast_basic
+set_analysis_view -setup av_fast -hold av_fast
+</code>
+
+Finalement, pour effectivement charger toutes ces configurations dans //Innovus//, vous devez utiliser la commande suivante:
+
+<code>
+[innovus]% init_design
+</code>
+
+==== Partitionnement ====
+
+Le partitionnement consiste dans un premier temps à définir la taille du circuit intégré ainsi que l’emplacement des différents modules constituant le système, et dans un second temps à organiser l’alimentation du circuit et les pins d’entrées/sorties.
+
+=== Floorplan ===
+
+<imgcaption fig:floor| Spécifier le //floorplan//>
+{{3_floorplan.png?nolink|Spécifier le //floorplan//}}
+</imgcaption>
+
+La spécification du //floorplan// consiste à définir les dimensions du dé (//die//) et du //core//. Pour spécifier le floorplan, sélectionnez: ''Floorplan -> Specify Floorplan''. La fenêtre qui s’ouvre (<imgref fig:floor>) vous donne le choix de définir les dimensions du //core// et du dé. Le champs ''Ratio H/W'' correspond au ratio entre la hauteur et la largeur du //core//. Le champs ''Core Utilization'' permet de spécifier le pourcentage d’occupation des cellules standards par rapport aux dimensions du //core//. La valeur 0.6 correspond à 60% d’utilisation, ce qui laisse une bonne marge pour le routage. Les champs ''Core to Die Boundary'' déterminent les marges (en $\mu$m entre le //core// et le dé. C’est dans cet intervalle que seront placées les alimentations et les pins d’entrées sorties.
+
+Alternativement vous pouvez utiliser l’interface en ligne de commande pour spécifier le floorplan:
+
+<code:tcl>
+[innovus]% floorPlan -site CoreSite -r 0.9 0.6 1 1 1 1 
+</code>
+
+=== Alimentations ===
+
+<imgcaption fig:globalnet| Connecter les alimentations>
+{{3_GlobalNet.png?nolink|Connecter les alimentations}}
+</imgcaption>
+
+La première étape pour alimenter le circuit consiste à effectuer des connexions //logiques// entre les noeuds d’alimentation (''VDD'' et ''VSS'') et les cellules standards. D’autre part, les constantes sont aussi connectées à cette étape (''tiehi'' connecté à ''VDD'' pour le 1 logique, et ''tielo'' connecté à ''VSS'' pour le 0 logique). Sélectionnez ''Power -> Connect Global Net''. La fenêtre qui s’ouvre (<imgref fig:globalnet>) liste des noeuds à connecter et permet de sélectionner les instances et les pins cibles.
+
+Alternativement vous pouvez utiliser l’interface en ligne de commande pour connecter les alimentations:
+
+<code:tcl>
+[innovus]% globalNetConnect VDD -type pgpin -pin VDD -inst * -override
+[innovus]% globalNetConnect VSS -type pgpin -pin VSS -inst * -override
+[innovus]% globalNetConnect VDD -type tiehi -inst * -override
+[innovus]% globalNetConnect VSS -type tielo -inst * -override
+</code>
+
+<imgcaption fig:stripes| Positionner les alimentations>
+{{3_VDD_stripes.png?nolink|Positionner les alimentations}}
+</imgcaption>
+
+La deuxième étape pour alimenter le circuit consiste à positionner des bandes (ou des anneaux) d’alimentations autour du //core//. Ici, nous allons simplement positionner une bande ''VDD'' du côté gauche du //core// et une bande //VSS// du côté droit du //core//, en utilisant la couche ''Metal 1''. Sélectionnez ''Power -> Power Planning -> Add Stripe''. Pour ''VDD'' complétez la fenêtre de configuration comme le montre la <imgref fig:stripes>. Assurez vous de sélectionner: ''Start from -> Left'', puis cliquez sur ''Apply''. Pour ''VSS'', remplacez simplement le nom du noeud par ''VSS''. Assurez vous de sélectionner: ''Start from -> Right'', puis cliquez sur ''Apply''.
+
+Alternativement vous pouvez utiliser l’interface en ligne de commande pour positionner les bandes d’alimentation:
+
+<code:tcl>
+[innovus]% addStripe -nets VDD -layer Metal1 -direction vertical -width 0.6 \
+                     -number_of_sets 1 -start_from left -start_offset -0.8
+
+[innovus]% addStripe -nets VSS -layer Metal1 -direction vertical -width 0.6 \
+                     -number_of_sets 1 -start_from right -start_offset -0.8                       
+</code>
+
+<imgcaption fig:routestripes| Router les alimentations>
+{{3_PowerRoute.png?nolink|Router les alimentations}}
+</imgcaption>
+
+Enfin, la dernière étape pour alimenter le circuit consiste à distribuer les alimentations dans le //core// de manière à alimenter les cellules standards. Les zones horizontales définies par le //floorplan// représentent les zones où les cellules standards vont se positionner lors du placement. Pour faciliter cette étape, toutes les cellules standards ont la même hauteur, et sont alimentées de la même manière, avec des connexions à ''VDD'' et à ''VSS'' alternativement en haut et en bas. Distribuer les alimentations consiste donc à router des fils connectés à ''VDD'' et des fils connectés à ''VSS'' le long des lignes horizontales. Sélectionnez: ''Route -> Special Route'' et complétez les champs tels que le montre la <imgref fig:routestripes>.
+
+Alternativement vous pouvez utiliser l’interface en ligne de commande pour router les alimentations:
+
+<code:tcl>
+[innovus]% sroute -nets { VDD VSS } -connect { corePin floatingStripe }
+</code>
+
+=== Entrées/Sorties ===
+
+<imgcaption fig:pin| Positionner des pins d'entrées/sorties>
+{{3_pin_top.png?nolink|Positionner des pins d'entrées/sorties}}
+</imgcaption>
+
+Par défaut lors de l'initialisation les pins d’entrées/sorties sont positionnées en bas à gauche du dé. Cette étape du partitionnement consiste à positionner les pins d’entrées/sorties autour du circuit intégré, ainsi qu’à sélectionner la couche physique qui sera utilisée pour router les signaux associés. Sélectionnez: ''Edit -> Pin Editor''. Utilisez cette interface pour placer les pins ''i_clk'', ''i_rstn'' et ''i_en'' en haut du circuit comme le montre la <imgref fig:pin>. Utilisez la couche ''Metal 2'', placez les pins entre les points ''{2,9}'' et ''{10,9}'', et choisissez la direction ''Clockwise''. De même, placez les pins du signal ''o_cnt[3:0]'' en bas du circuit, avec la couche ''Metal 2'', entre les points ''{1,0}'' et ''{11,0}'', dans la direction ''Counterclockwise''.
+
+Alternativement vous pouvez utiliser l’interface en ligne de commande pour positionner les pins d’entrées et de sorties:
+
+<code:tcl>
+[innovus]% setPinAssignMode -pinEditInBatch true
+
+[innovus]% editPin -start 2 9 -end 10 9 -pin [list i_clk i_rstn i_en] \
+                   -side Top -layer 2 -spreadType range -spreadDirection clockwise 
+
+[innovus]% editPin -start 1 0 -end 11 0 -pin [list o_cnt[0] o_cnt[1] o_cnt[2] o_cnt[3]] \
+                   -side Bottom -layer 2 -spreadType range -spreadDirection counterclockwise 
+</code>
+
+Finalement, vous devez obtenir un résultat similaire à la <imgref fig:layoutpin>. Notez l’alternance des fils ''VDD'' et ''VSS'' en ''Metal 1'' le long des lignes du //floorplan//. On compte ici 4 zones pour positionner les cellules standards. Notez également les positions des pins d’entrées en haut du dé, et des pins de sortie en bas du dé.
+
+<imgcaption fig:layoutpin| Dessin des masques du compteur après le Partitionnement>
+{{3_Layout_Pin.png?nolink|Dessin des masques du compteur après le Partitionnement}}
+</imgcaption>
+
+==== Placement ====
+
+Maintenant que l’étape de partitionnement est terminée, nous pouvons lancer la procédure de placement des cellules standards. Notez cependant que dans un flot de conception plus complet, nous devrions spécifier les //scan chains// à ce stade. Cependant nous avons choisi de mettre de côté les aspects liés à la testabilité dans ces laboratoires. Pour spécifier que les //scan chains// ne doivent pas être insérées, exécutez les deux commandes suivantes:
+
+<code:tcl>
+[innovus]% setPlaceMode -place_global_reorder_scan false
+[innovus]% deleteAllScanCells
+</code>
+
+De plus, avant de démarrer le placement il faut spécifier à l’outil quelle technologie est utilisée, de sorte qu’il place (et route) les cellules standards en accord avec cette configuration.
+
+<code>
+[innovus]% setDesignMode -process 45
+</code>
+
+Pour démarrer le placement des cellules standards, sélectionnez ''Place -> Place Standard Cells''. Vous pouvez conserver les configurations par défaut. Alternativement vous pouvez utiliser l’interface en ligne de commande pour réaliser le placement automatique des cellules standards:
+
+<code:tcl>
+[innovus]% placeDesign
+</code>
+
+
+<imgcaption fig:layoutplace| Dessin des masques du compteur après le Placement>
+{{3_Layout_Place.png?nolink|Dessin des masques du compteur après le Placement}}
+</imgcaption>
+
+Comme on peut le voir, l’outil a réalisé un premier routage des cellules. Ce routage n’est pas le routage final, il est simplement là pour aider l’outil de placement à placer efficacement les cellules en prenant en compte le routage. Pour voir le détail des cellules, sur la droite de la fenêtre d’//Innovus//, vous pouvez désélectionner ''Net'' et sélectionner ''Cell''. Vous obtiendrez un résultat similaire à la <imgref fig:layoutplace>.
+
+Notez que les cellules n’occupent pas la totalité de la surface disponible. Les espaces qui existent entre les cellules (dû au fait que nous avons spécifié les dimensions du //core// à 60% d’occupation des cellules) seront utiles à deux reprises:
+
+  - Durant l’étape de synthèse de l’arbre d’horloge, les espaces entre les cellules permettent à l’outil de placer automatiquement les //buffers// de l’arbre d’horloge au plus près des éléments séquentiels.
+  - Durant l’étape de routage, les espaces entre les cellules permettent à l’outil de modifier l’emplacement des cellules pour éviter les congestions.
+
+En revanche, ces espaces ne sont pas bon du point de vue de la fabrication car ils brisent la continuité des couches semiconductrices et peuvent créer des capacités parasites. Une fois l’ensemble des cellules placées, nous remplirons ces espaces avec des cellules spécialisées appelées //Fillers//.
+
+==== Synthèse de l’arbre d’horloge ====
+
+La majorité des systèmes séquentiels étant synchrones, leur fonctionnement est dépendant d’un ou plusieurs signaux d’horloge qui orchestrent les opérations. Ces signaux d’horloges doivent être distribués sur l’ensemble des éléments séquentiels du circuits, et doivent respecter un certain nombre de contraintes. D’une manière générale, il s’agit de conserver l’intégrité des signaux d’horloge à travers le circuit, et de maitriser la synchronicité des événements d’un élément séquentiel à l’autre. Pour garantir le respect de ces contraintes, une étape spécifique du flot de conception, appelée //**clock tree synthesis**// (CTS), a été introduite dans les outils de conception automatisés.
+
+L’arbre d’horloge est constitué de //buffers// qui régénèrent le signal d’horloge dans le circuit. En général, une étape d’optimisation (pre-CTS) prépare le circuit avant l’insertion des //buffers//. De même, une étape d’optimisation post-CTS est réalisée après leur placement. Des //buffers// de faible taille sont utilisés à proximité des éléments séquentiels (les "feuilles" de l’arbre), tandis que des //buffers// de taille de plus en plus importante sont utilisés à mesure que l’on s’approche de la pin d’horloge (le "tronc" de l’arbre). Étant donnée l’importance de ces //buffers// sur les performances du système, des cellules spécifiques sont conçues dans ce but. Avant de lancer la procédure de synthèse de l’arbre d’horloge, il faut donc configurer les cellules à utiliser pour générer les //buffers//.
+
+  * Optimisations qui précèdent la synthèse de l’arbre d’horloge:
+
+<code:tcl>
+[innovus]% optDesign -preCTS
+</code>
+
+  * Définition des cellules standards à utiliser pour générer les //buffers//:
+
+<code:tcl>
+[innovus]% set_ccopt_property buffer_cells [list CLKBUFX20 CLKBUFX16 CLKBUFX12 CLKBUFX8 CLKBUFX6 CLKBUFX4 CLKBUFX3 CLKBUFX2]
+[innovus]% set_ccopt_property inverter_cells [list CLKINVX20 CLKINVX6 CLKINVX8 CLKINVX16 CLKINVX12 CLKINVX4 CLKINVX3 CLKINVX2 CLKINVX1]
+[innovus]% set_ccopt_property use_inverters true                                               
+</code>
+
+  * Synthèse de l’arbre d’horloge:
+
+<code:tcl>
+[innovus]% ccopt_design
+</code>
+
+  * Optimisations qui succèdent à la synthèse de l’arbre d’horloge:
+
+<code:tcl>
+[innovus]% optDesign -postCTS
+</code>
+
+
+==== Routage ====
+
+Dans un premier temps, nous allons configurer une option de l’outil qui permet de réaliser le routage de façon à satisfaire les contraintes temporelles du système:
+
+<code:tcl>
+[innovus]% setNanoRouteMode -quiet -routeWithTimingDriven true
+</code>
+
+Pour lancer la procédure de routage sélectionnez: ''Route -> NanoRoute -> Route''. Vous pouvez conserver les paramètres par défaut. Alternativement vous pouvez utiliser l’interface en ligne de commande pour effectuer le routage:
+
+<code:tcl>
+[innovus]% routeDesign -globalDetail
+</code>
+
+Finalement, nous allons combler les espaces vide entre les cellules avec des //Fillers//. Pour cela, nous utiliserons la commande ''addFiller'', qui prend en entrée la liste des cellules standards dédiées pour cette opération. Vous devriez obtenir un résultat similaire à la <imgref fig:layoutroute>.
+
+<code:tcl>
+[innovus]% addFiller -cell FILL32 FILL16 FILL8 FILL4 FILL2 FILL1 -prefix FILLER
+</code>
+
+<imgcaption fig:layoutroute| Dessin des masques du compteur après le Routage>
+{{3_Layout_Route.png?nolink|Dessin des masques du compteur après le Routage}}
+</imgcaption>
+
+==== Vérifications ====
+
+À ce stade, il convient de vérifier que les étapes de placement et de routage ont conduit à un circuit fonctionnel. En effet, les étapes de vérifications permettent de s’assurer, autant que possible, que le système sera fonctionnel après la fabrication. On distingue trois principaux types de vérifications:
+
+  - **STA** (//Static Timing Analysis//): L’analyse temporelle statique confronte les contraintes temporelles définies au début de l’implémentation avec les délais évalués dans le circuits. À ce stade cette analyse prend en compte les délais des fils, des portes logiques, des capacités parasites, de l’arbre d’horloge etc. Elle permet de garantir, avec une certaine marge appelée //slack//, que le système peut fonctionner à la fréquence spécifiée.
+  - **DRC** (//Design Rule Check//): Les vérifications DRC concernent les aspects physiques du circuit. Il s’agit de vérifier que les règles de conception (règles de dessins, de connectivité, de géométrie etc.) ont été respectées, garantissant ainsi l’intégrité électrique du système.
+  - **LVS** (//Layout Versus Schematic//): Les vérifications LVS garantissent que le circuit post-PnR est électriquement identique au circuit post-synthèse. C'est à dire, que les opérations de placement et de routage, d'insertion de l'arbre d'horloge et des //scan-chains// etc. n'ont pas modifié les fonctionnalités du circuit. 
+    
+Dans les deux cas, si les résultats d’une vérification ne sont pas satisfaisant, il faut répéter les étapes précédentes en modifiants certaines options et paramètres. On peut par exemple reprendre le routage avec des options plus agressives sur le timing si le STA donne de mauvais résultats.
+
+=== DRC ===
+
+Pour lancer la procédure de DRC sélectionnez: ''Verify -> Verify DRC''. Vous pouvez conserver les paramètres par défaut. Alternativement vous pouvez utiliser l’interface en ligne de commande pour effectuer un DRC avec la commande ''verify_drc'' (en s’assurant d’abord de définir l’emplacement du fichier où sera sauvegardé le rapport de DRC). De façon similaire, vous pouvez vérifier la connectivité des noeuds du circuit en suivant: ''Verify -> Verify Connectivity'', ou en utilisant la commande ''verifyConnectivity''.
+
+  * Vérification des règles de dessin (DRC):
+
+<code:tcl>
+[innovus]% set_verify_drc_mode -report $::env(PNR_REP_DIR)/compteur.drc.rpt
+[innovus]% verify_drc
+</code>
+
+  * Vérification de la connectivité:
+
+<code:tcl>
+[innovus]% verifyConnectivity -type all -report $::env(PNR_REP_DIR)/compteur.con.rpt
+</code>
+
+Notez que le prompt d’//Innovus// donne un résumé des //violations de DRC// détectées par les outils de vérifications, et que les zones concernées sur le dessin des masques sont mises en évidence. Pour voir le détails des violations de DRC et de connectivité, sélectionnez: ''Tools -> Violation Browser''.
+
+=== STA ===
+
+Avant de lancer la procédure de vérification temporelle, il faut configurer l’outil pour qu’il prenne en compte les variations temporelles post-routage. Pour ce faire exécutez la commande suivante:
+
+<code:tcl>
+[innovus]% setAnalysisMode -analysisType onChipVariation
+</code>
+
+Pour lancer la procédure de vérification temporelle complète, sélectionnez: ''Timing -> Report Timing''. Sélectionnez ''Post-Route'', et modifiez l’emplacement du répertoire de destination pour ''reports/timing''. Alternativement vous pouvez utiliser l’interface en ligne de commande pour effectuer l’analyse temporelle (//visualisez ensuite le résultat avec un éditeur de texte//).
+
+<code:tcl>
+[innovus]% report_timing > $::env(PNR_REP_DIR)/compteur.tim.rpt
+</code>
+
+==== Sauvegardes ====
+
+<imgcaption fig:oa| Création d'une librairie //Open Access//>
+{{3_OAlib.png?nolink|Création d'une librairie //Open Access//}}
+</imgcaption>
+
+À tout moment pendant l’implémentation vous pouvez sauvegarder votre travail dans une librairie OA. Pour ce faire, vous devez dans un premier temps créer cette librairie en sélectionnant: ''File -> Create OA Library''. La librairie doit être attachée aux librairies de la technologie ''GPDK45'', comme le montre la <imgref fig:oa>.
+
+Alternativement vous pouvez utiliser l’interface en ligne de commande pour créer la librairie
+
+<code:tcl>
+[innovus]% createLib liboa -attachTech gsclib045_tech
+</code>
+
+Pour sauvegarder votre circuit, sélectionnez ''File -> Save Design''. Assurez vous de sélectionner la librairie que vous venez de créer, de choisir le type OA, et la vue //layout//. Alternativement vous pouvez utiliser l’interface en ligne de commande pour sauvegarder le circuit:
+
+<code:tcl>
+[innovus]% saveDesign -cellview {liboa compteur layout}
+</code>
diff --git a/doc/wiki/4_energie.dwiki b/doc/wiki/4_energie.dwiki
new file mode 100644
index 0000000000000000000000000000000000000000..591da2dd74c66293ee8b2408755b85543c4cb230
--- /dev/null
+++ b/doc/wiki/4_energie.dwiki
@@ -0,0 +1,195 @@
+
+====== Estimation de la consommation d'énergie des circuits intégrés numériques ======
+
+— //[[mickael.fiorentino@polymtl.ca|Mickael Fiorentino]] 2019/07/10// —
+
+Dans ce tutoriel nous présentons deux méthodes simples pour estimer la consommation d’énergie d’un circuit intégré, à travers l’exemple du compteur BCD. Les étapes de [[tutos:compteur:1_simulation|simulation]], de [[tutos:compteur:2_synthese|synthèse]], et de [[tutos:compteur:3_implementation|placement & routage]], sont des prérequis nécessaires à la poursuite de ce tutoriel. Les méthodes présentées ici supposent que le circuit implémenté est fonctionnel, et que son dessin des masques est sauvegardé dans une librairie //Open Access// (OA).
+
+Ce tutoriel présente ces deux méthodes pour estimer la consommation d’énergie d’un circuit intégré à partir de l’outil **Voltus**:
+
+  - ** la méthode statique**, où seule la fréquence d’horloge est utilisée pour estimer l’activité du système
+  - **la méthode dynamique**, (aussi appelée //vector-driven//), qui utilise l’activité générée lors de la simulation temporelle du circuit. Cette méthode fournit des résultats plus réalistes que la méthode statique, mais elle est plus longue à mettre en oeuvre. 
+
+L’estimation de la consommation d’énergie d’un circuit est fondée sur l’estimation de son activité, et sur l’estimation de la puissance dissipée par son dessin des masques. Pour estimer l’activité du circuit, on utilise les changement de valeurs des signaux durant une simulation temporelle, qui sont sauvegardés dans un fichier VCD. Plus le banc d’essai contient de stimuli différents, plus l’estimation de l’activité sera précise. La procédure pour enregistrer l’activité du compteur (post-PnR) dans un fichier VCD est détaillée dans la partie du tutoriel qui concerne la [[tutos:compteur:1_simulation:#Enregistrement de l’activité|simulation]].
+
+L’estimation de la puissance dissipée par le circuit dépend du dessin des masques, qui affecte le nombre et la taille des capacités d’interconnexion, mais également de la technologie utilisée, qui influe sur les fuites de courant et sur la puissance consommée par les cellules standards. On distingue ainsi trois principales contributions à la consommation de puissance d’un circuit intégré:
+
+$$P = P_s + P_i + P_L$$
+
+  - **Puissance de commutation** (//Switching power//, $P_s$): Il s’agit de la puissance consommée lors de la charge et de la décharge des capacités formées par les interconnexions. En général il s’agit de la contribution dominante, que l’on peut exprimer par: $P_s = \frac{C_L}{2} \times V^{2} \times F \times A$, où $C_L$ est la charge, $V$ la tension, $F$ la fréquence, et $A$ l’activité moyenne du système, évaluée à partir d’une simulation, ou extrapolée à partir de la fréquence.
+  - **Puissance interne** (//Internal power//, $P_i$): Il s’agit de la puissance consommée lors de la charge et de la décharge des capacités formées dans les cellules standards. Cette contribution est calculée à partir des tables de puissance fournies dans les fichiers ''.lib'' de la technologie. Elles sont générées par une simulation //spice// réalisée par le fabricant durant la phase de caractérisation des cellules.
+  - **Fuites de courant** (//Leakage power//, $P_L$): Il s’agit de la puissance consommée par les transistors lorsqu’ils ne sont pas sollicités. Cette contribution dépend de l’état du transistor (//on// ou //off//), et est également calculée à partir des fichiers ''.lib'' de la technologie.
+
+===== Environnement de travail =====
+
+Avant de débuter ce tutoriel, assurez vous d’avoir un dessin des masques fonctionnel, réalisé avec //Innovus// et sauvegardé dans une librairie OA, ainsi qu’un fichier VCD, issu d’une simulation post-PnR avec //Modelsim//.
+
+==== Démarrer l’outil ====
+
+//Voltus// s’exécute sur les postes de travail Linux dans un environnement ''tcsh''. L’initialisation de l’environnement de travail s’effectue à partir du fichiers de configuration ''setup.csh''. Avant de lancer //Voltus//, vérifiez que le fichier ''cds.lib'' est bien présent
+
+  * Se placer a la racine du projet et configurer l'environnement
+
+<code:bash>
+[shell]% cd ~/Tutos/compteur
+[shell]% source setup.csh
+</code>
+
+  * Se placer dans le repertoire de travail et demarrer l'outil //Voltus//
+
+<code:tcl>
+[shell]% cd implementation/pnr
+[shell]% voltus
+</code>
+
+Notez que //Voltus// est un outil qui se contrôle avec l’interface graphique en complément de l’interface en ligne de commande. Après avoir lancé l’outil, le prompt de votre terminal devient l’interpréteur de //Voltus//:
+
+<code tcl>
+[voltus]%
+</code>
+
+==== Obtenir de l’aide ====
+
+En complément de ce guide, vous pouvez obtenir de l’aide directement à partir de //Voltus//. Pour connaître le détail d’une commande vous pouvez invoquer la commande ''help'' et la commande ''man'' dans l’interpréteur:
+
+<code tcl>
+[voltus]% help help*
+[voltus]% man help
+</code>
+
+Vous avez également accès à l’intégralité de la documentation de //Voltus//, directement dans l’aide //Cadence//. Pour lancer l’aide //Cadence//, et accéder à toute la documentation, utilisez la commande:
+
+<code:tcl>
+[shell]% voltus_help
+</code>
+
+Vous pouvez naviguer dans l’aide en parcourant les différents dossier, comme le montre la figure suivante:
+
+<imgcaption fig:help| Documentation de Voltus>
+{{4_help.png?nolink|Documentation de //Voltus//}}
+</imgcaption>
+
+===== Configurations préliminaires =====
+
+==== Ouverture du dessin des masques ====
+
+Avant de débuter les procédures d’estimation de la consommation d’énergie, il faut charger le dessin des masques du compteur dans //Voltus// à partir de de la libraire OA créée lors de [[tutos:compteur:3_implementation|l'implémentation]]. Sélectionnez ''File -> Read Design'' et remplissez les champs comme le montre la <imgref fig:help>. Assurez vous de sélectionner ''Data Type -> OA'', et de cocher la case ''Read Physical Data''.
+
+<imgcaption fig:restore| Charger le dessin des masques du compteur>
+{{4_restore.png?nolink|Charger le dessin des masques du compteur}}
+</imgcaption>
+
+Alternativement vous pouvez utiliser l’interface en ligne de commande pour charger le dessin des masques:
+
+<code:tcl>
+[voltus]% read_design -cellview [list liboa compteur layout] -physical_data
+</code>
+
+==== Caractérisation des cellules standards ====
+
+Dans un circuit intégré il est commun de réutiliser les mêmes cellules standards à de multiples reprises. Pour éviter de recompiler les données relatives à la consommation de puissance pour chacune d’entre elles, on caractérise chaque cellule standard en amont de l’analyse de puissance, réduisant ainsi le temps requis entre chaque estimation de puissance. Sélectionnez ''Power & Rail -> Set PowerGrid Library Mode''. Remplissez chacun des champs comme le montre la <imgref fig:restore>. En particulier, sélectionnez: ''Extraction Tech File -> /CMC/kits/AMSKIT616_GPDK/tech/gsclib045/gsclib045/qrc/qx/gpdk045.tch''. Pour lancer la procédure de caractérisation, sélectionnez: ''Power & Rail -> Generate PowerGrid Library'', et modifiez l’emplacement de destination pour: ''reports/power''.
+
+Alternativement, vous pouvez utiliser l’interface en ligne de commande pour extraire les caractéristiques de puissance des cellules standards:
+
+  * Configuration du mode d’extraction:
+
+<code:tcl>
+[voltus]% set_pg_library_mode -extraction_tech_file $::env(BE_QRC_LIB)/gpdk045.tch \
+                              -celltype techonly -default_area_cap 0.5             \
+                              -decap_cells DECAP* -filler_cells FILL*              \
+                              -power_pins {VDD 1.1} -ground_pins VSS
+</code>
+
+  * Lancement de la caractérisation
+
+<code tcl>
+[voltus]% generate_pg_library -output $::env(PNR_REP_DIR)/power
+</code>
+
+===== Méthode Statique =====
+
+La méthode d’estimation //statique// donne un aperçu rapide de la puissance dissipée par le système. Ici, seule la fréquence d’horloge est utilisée pour estimer l’activité du système. La procédure se déroule en deux parties.
+
+  * Vous devez premièrement configurer le mode d’analyse de puissance à effectuer. Pour cela, sélectionnez ''Power & Rail -> Set Power Analysis Mode'', et sélectionnez ''Static''.
+
+<imgcaption fig:static-setup| Configuration de la méthode statique>
+{{4_static_setup.png?nolink|Configuration de la méthode statique}}
+</imgcaption>
+
+  * Ensuite sélectionnez ''Power & Rail -> Run Power Analysis''. Configurez la fréquence d’opération dominante du système à ''1 GHz'' (tel que spécifié dans le fichier SDC), puis modifiez l’emplacement du répertoire de destination pour ''reports/power''. Enfin sélectionnez ''Apply'' pour lancer l’analyse de puissance. Vous devriez obtenir un résultat dans l’interpréteur, ainsi qu’un rapport de puissance dans le dossier de destination.
+
+<imgcaption fig:static-run| Lancement de la méthode statique>
+{{4_static_run.png?nolink|Lancement de la méthode statique}}
+</imgcaption>
+
+ Alternativement, vous pouvez utiliser l’interface en ligne de commande pour réaliser cette même procédure de façon automatisée:
+
+  * Configuration du mode d’analyse de puissance //statique//:
+
+<code:tcl>
+[voltus]% set_power_analysis_mode -reset
+[voltus]% set_power_analysis_mode -method static -analysis_view av_fast -corner max
+</code>
+
+  * Configuration de l’activité du circuit:
+
+<code:tcl>
+[voltus]% set_default_switching_activity -reset
+[voltus]% set_default_switching_activity -input_activity 0.2 -period 1.0  
+</code>
+
+  * Lacement de l’analyse de puissance:
+
+<code:tcl>
+[voltus]% report_power -output $::env(PNR_REP_DIR)/power \
+                       -format detailed -report_prefix compteur_stat
+
+</code>
+
+===== Méthode Dynamique =====
+
+La méthode d’estimation //dynamique// donne un aperçu plus réaliste de la puissance dissipée par le système. Ici, nous utilisons les résultats d’une simulation temporelle, sauvegardés dans un fichier VCD, pour évaluer l’activité du système. Notez que le banc d’essai est ici d’une importance capitale: L’estimation de la consommation d’énergie du système sera d’autant plus réaliste que les vecteurs de test générés par le banc d’essai pour stimuler le système reflètent des cas de figures variés.
+
+  * Premièrement, configurez le mode d’analyse en sélectionnant ''Power & Rail -> Set Power Analysis Mode''. Sélectionnez d’abord ''Dynamic'' et ''Vectorbased'', puis sélectionnez ''Analysis View -> av_fast'' et ''Corner -> max''. Enfin, sélectionnez ''PowerGrid Libraries -> reports/power/techonly.cl'', qui correspond aux librairies caractérisées dans la phase de configuration.
+
+<imgcaption fig:dynamic-setup| Configuration de la méthode dynamique>
+{{4_dynamic_setup.png?nolink|Configuration de la méthode dynamique}}
+</imgcaption>
+
+  * Ensuite sélectionnez ''Power & Rail -> Run Power Analysis''. Ici nous allons choisir ''Activity File -> VCD'', et sélectionner le fichier VCD correspondant à la simulation post-PnR à l’emplacement ''~/Tutos/compteur/simulation/pnr/compteur.pnr.vcd''. Sélectionnez: ''Scope -> compteur_tb/dut'', ''Start -> 0'' et ''End -> 39''. Cliquez sur ''Add'' pour valider l’ajout du fichier d’activité. Enfin, modifiez l’emplacement du répertoire de destination pour ''reports/power''. Sélectionnez ''Apply'' pour lancer l’analyse de puissance. L’analyse dynamique devrait prendre plus de temps que l’analyse statique. Vous obtiendrez finalement un rapport de puissance dans le dossier de destination.
+
+<imgcaption fig:dynamic-run| Lancement de la méthode dynamique>
+{{4_dynamic_run.png?nolink|Lancement de la méthode dynamique}}
+</imgcaption>
+
+Alternativement, vous pouvez utiliser l’interface en ligne de commande pour réaliser cette même procédure de façon automatisée:
+
+  * Configuration du mode d’analyse de puissance //dynamique//:
+
+<code:tcl>
+[voltus]% set_power_analysis_mode -reset
+[voltus]% set_power_analysis_mode -method dynamic_vectorbased                   \
+                                  -analysis_view av_fast -corner max            \
+                                  -power_grid_library reports/power/techonly.cl \
+                                  -report_stat true                             \
+                                  -enable_rtl_vectorbased_dynamic_analysis true \
+                                  -create_binary_db true                        \
+                                  -disable_static false                         \
+                                  -write_static_currents true                   \
+                                  -report_missing_flop_outputs false
+</code>
+
+  * Configuration de l’activité du circuit:
+
+<code:tcl>
+[voltus]% set_default_switching_activity -reset
+[voltus]% read_activity_file -format VCD $::env(SIM_PNR_DIR)/compteur.pnr.vcd \
+                             -scope compteur_tb/dut -start 0 -end 39
+</code>
+
+  * Lacement de l’analyse de puissance:
+
+<code:tcl>
+[voltus]% report_power -output $::env(PNR_REP_DIR)/power \
+                       -format detailed -report_prefix compteur_dyn
+</code>
diff --git a/doc/wiki/start.dwiki b/doc/wiki/start.dwiki
new file mode 100644
index 0000000000000000000000000000000000000000..de046432bda07b52ba6bd602d26c26b108156106
--- /dev/null
+++ b/doc/wiki/start.dwiki
@@ -0,0 +1,33 @@
+
+====== Conception de circuits intégrés numériques ======
+
+— //[[mickael.fiorentino@polymtl.ca|Mickael Fiorentino]] 2019/07/10// —
+
+Ce tutoriel s'adresse aux checheurs du GRM ainsi qu'aux étudiants du cours [[https://www.polymtl.ca/etudes/cours/circuits-integres-tres-grande-echelle|ELE8304]]. Il couvre la conception de circuits intégrés numériques à partir des outils de conception automatisés disponibles aux laboratoires [[https://www.gr2m.polymtl.ca/|GRM]] et [[https://www.gr2m.polymtl.ca/|VLSI]].
+
+Il est basé sur un **compteur BCD** décrit en langage VHDL:
+
+  * Sur vos postes de travail du GRM ou du laboratoire VLSI, placez vous dans le répertoire ''Tutos'':
+
+<code:bash>
+[shell]% mkdir -p ~/Tutos/
+[shell]% cd ~/Tutos/
+</code>
+
+  * Téléchargez les sources dans le répertoire ''git'': [[https://git.cmc.ca/mickael.fiorentino/vlsi_numerique|compteur.git]].
+
+<code:bash>
+[shell]% git clone https://git.cmc.ca/mickael.fiorentino/vlsi_numerique compteur
+</code>
+
+  * Téléchargez les sources au format ''zip'': {{tutos:compteur:compteur.zip?linkonly|compteur.zip}}
+
+<code:bash>
+[shell]% unzip compteur.zip -d compteur
+</code>
+
+Le tutoriel est décomposé en plusieurs parties, chacune couvrant une partie du flot de concepion standard en microélectronique:
+  - [[tutos:compteur:1_simulation|Simulation]]
+  - [[tutos:compteur:2_synthese|Synthèse]]
+  - [[tutos:compteur:3_implementation|Placement & Routage]]
+  - [[tutos:compteur:4_energie|Évaluation de la consommation d'énergie]]