summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--.gitignore3
-rw-r--r--README28
-rw-r--r--rapport_simulateur.tm119
3 files changed, 143 insertions, 7 deletions
diff --git a/.gitignore b/.gitignore
index be8fd58..2a4dcc9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,6 @@ csim/csim
tests/*.net
tests/*.snet
tests/*.dumb
+rapport_simulateur.ps
+rapport_simulateur.pdf
+*.tm~
diff --git a/README b/README
index 81eadea..47f8935 100644
--- a/README
+++ b/README
@@ -16,7 +16,7 @@ sched/
Output : a netlist with topologically sorted operators
plus a dumbed-down version for input to the C circuit simulator
This program is also capable of a few optimisation (usually reduces netlist
- size by 1/4).
+ size by 1/4 or 1/3).
$ cd sched/
$ ocamlbuild main.byte
@@ -25,7 +25,7 @@ csim/
This program does NOT do the scheduling.
This program does NOT read a netlist, it reads a specifically formatted
dumbed-down netlist, that is output by the scheduler.
- $ cd csim
+ $ cd csim/
$ make
camlsim/
@@ -39,6 +39,9 @@ camlsim/
minijazz/
The MiniJazz compiler (given by the teachers).
+tests/
+ Various test files.
+
*.pdf
Documentation about the project.
@@ -85,6 +88,8 @@ The right shift is also inverted.
The dumbed-down netlist format (OLD FORMAT)
-------------------------------------------
+This is the description of the old format, not used anymore.
+
The C simulator does NOT read a properly formatted netlist, but only a file
representing it written in a simple format, that can be parsed with only calls
to `scanf`. The file is organized as follows :
@@ -145,6 +150,8 @@ whatever - anyway, no need to recalculate them at every iteration).
The dumbed-down netlist format (NEW FORMAT)
-------------------------------------------
+This is the description of the format currently used by the C simulator.
+
<var count>
[for each variable]
<var size> <var name>
@@ -208,17 +215,24 @@ How ROMs are handled
--------------------
The MiniJazz language has many flaws, and one is the impossibility to specify
-what is to be loaded in a ROM. One possibility (not implemented yet) would be
-that each ROM-type equation uses data from a file which is found by looking at
-the name of the variable that is read from the ROM. For example, if we have :
+what is to be loaded in a ROM (it can be specified in the .mj file, but it won't
+appear in the generated .net file).
+
+To know what file to load in a ROM chip, we recognize a certain prefix in the
+name of the variable holding the ROM. For example, if we have in a netlist the
+following line :
+
decode7_128 = ROM 4 7 _l_42_122
+
which is a possible output for the MiniJazz compiler, and if the simulator is
provided with the command-line argument :
+
-rom decode7 path/to/decode7.rom
+
then the simulator will detect the prefix `decode7` in the variable name
-decode7_128, and use the ROM from the file specified on the command line.
+decode7_128, and use the ROM data from the file specified on the command line.
-Suggested format for the ROM files :
+The format of a ROM file is as follows :
<address width> <word size>
<data>
diff --git a/rapport_simulateur.tm b/rapport_simulateur.tm
new file mode 100644
index 0000000..a7352cf
--- /dev/null
+++ b/rapport_simulateur.tm
@@ -0,0 +1,119 @@
+<TeXmacs|1.0.7.19>
+
+<style|generic>
+
+<\body>
+ <doc-data|<doc-title|Rapport : simulateur de
+ circuit>|<doc-author|<author-data|<author-name|Alex
+ AUVOLAT>>>|<doc-date|2013-11-12 09h00>>
+
+ Dans le cadre du cours <em|Système Digital : de l'algorithme au circuit> de
+ <name|J.Vuillemin>, j'ai écrit un simulateur de circuit capable de faire
+ fonctionner un circuit préalablement compilé dans le langage MiniJazz.
+
+ Le simulateur que j'ai écrit est codé en C (essentiellement pour la
+ rapidité d'exécution), et nécessite un pré-traîtement des données par un
+ programme en Caml. Le simulateur en C ne lit pas directement les netlist
+ produites par MiniJazz, mais un fichier <verbatim|.dumb> qui est produit
+ par le pré-processeur.
+
+ Contenu de l'archive ci-jointe :
+
+ <\verbatim-code>
+ README
+
+ \ Diverses documentations. À lire.
+
+ \;
+
+ sched/
+
+ \ Dans ce répertoire se trouve le pré-processeur, qui effectue les
+ opérations suivantes :
+
+ \ - lecture d'une netlist
+
+ \ - tri topologique
+
+ \ - diverses optimisations
+
+ \ - écriture d'un fichier .net et d'un fichier .dumb contenant le
+ résultat.
+
+ Pour compiler le pré-processeur :
+
+ $ cd sched/
+
+ $ ocamlbuild main.byte
+
+ \;
+
+ csim/
+
+ \ Dans ce répertoire se trouve le simulateur en C.
+
+ Pour le compiler :
+
+ $ cd csim/
+
+ $ make
+
+ Les options du simulateur sont décrites lors de l'invocation de celui-ci
+ sans arguments.
+
+ \;
+
+ tests/
+
+ \ Ce répertoire contient un certain nombre de fichiers de test au format
+ minijazz. Le Makefile permet d'effectuer les appels au compilateur, au
+ pré-processeur et au simulateur avec la syntaxe suivante :
+
+ $ cd tests/
+
+ $ make nadder.sim \ \ \ \ # nadder.mj -\<gtr\> nadder.net -\<gtr\>
+ nadder.dumb -\<gtr\> csim
+ </verbatim-code>
+
+ Les points importants à souligner dans mon travail sont :
+
+ <\itemize>
+ <item>Définition d'un format de données intermédiaire pour les Netlist,
+ permettant l'écriture d'un simulateur en C. Définition conjointe de ce
+ format et de la structure du simulateur, afin d'écrire un simulateur le
+ mieux optimisé possible.
+
+ <item>Écriture d'un optimiseur de Netlist, qui est capable d'effectuer
+ plusieurs simplifications, dont :
+
+ <\itemize>
+ <item>propagation des constantes ;
+
+ <item>détection de variables au contenu identique ;
+
+ <item>suppression de variables inutiles ;
+
+ <item>suppression d'opérations arithmétiques inutiles.
+ </itemize>
+
+ L'application de ces passes d'optimisation réduit généralement la taille
+ d'une Netlist d'environ 30%.
+ </itemize>
+
+ Les efforts d'optimisation ont été faits dans l'idée que le simulateur
+ devra faire fonctionner un processeur MIPS à une fréquence raisonnable
+ (idéalement, plusieurs centaines, voire milliers, de cycle par seconde). Le
+ résultat de ce travail se voit sur les programmes <verbatim|clockHMS.mj> et
+ <verbatim|clock2.mj> qui définissent deux horloges qui comptent modulo 60
+ puis 60 puis 24 (donc qui comptent sur une journée, à un cycle par
+ seconde). Avec mon simulateur optimisé, les deux horloges sont capables de
+ simuler une journée entière de comptage, c'est-à-dire 86400 cycles, en 0.4
+ secondes pour le premier et 0.9 secondes pour le second, sur un ordinateur
+ moderne.
+</body>
+
+<\initial>
+ <\collection>
+ <associate|language|french>
+ </collection>
+</initial> \ No newline at end of file