path: root/README

Système Digital 2013-2014
Cours J.Vuillemin, TD T.Bourke

Alex AUVOLAT (Info 2013)


Introduction
============

Contents of the repository :
----------------------------

sched/
	A scheduler for netlists.
	Input : a netlist.
	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).
	$ cd sched/
	$ ocamlbuild main.byte

csim/
	A circuit simulator written in C.
	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
	$ make

camlsim/
	A circuit simulator written in OCaml.
	This program does NOT do the scheduling. The netlist must be passed through
	the scheduler first.
	This program is *highly incomplete* and not recomended for real use..
	$ cd camlsim/
	$ ocamlbuild simulator.byte

minijazz/
	The MiniJazz compiler (given by the teachers).

*.pdf
	Documentation about the project.



REFERENCES
----------

  -	Computer organization and design : the hardware/software interface
	4th ed
	Chapters 2 to 4



INTERNALS
=========

Convention for binary values
----------------------------

/!\ This convention is contrary to the one used in the example file nadder.mj
	(Therefore I have modified that file...)

The bit array [a_0 a_1 a_2 ... a_n-1] represents the decimal number :
	a_0 + 2*a_1 + 4*a_2 + ... + 2^(n-1)*a_n-1

When represented in binary, we write the bits in the order :
	a_0 a_1 a_2 ... a_n-1
Even though the normal notation for a binary number is :
	a_n-1 a_n-2 ... a_0

/!\ BINARY NUMBERS ARE WRITTEN REVERSE !

What we call a shift-left does a left shift on the representation as a binary
number, but we use the reverse notation here. Therefore in the ALU, the shift-left
should actually right-shift the bits when they are seen in the order a0, a1, ...

The right shift is also inverted.
- left shift -> right shift
- right shift -> left shift
- left shift logical -> rigth shift logical


The dumbed-down netlist format
------------------------------

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 :

<number of variables>
<variable types and names *1>
<inputs *2>
<outputs *2>
<number of equations>
<equation list *3>

*1 : this section contains for each variable a line in the format :
<variable width> <variable name>

In the rest of the files, the variables are referenced by their position in the
list given in *1 (the first line gives variable #0, etc.)

*2 : these section contain one line :
<number of inputs/outputs> [<variable number> ...]

*3 : this section contains one line for each equation, in the following format :
<destination variable> <equation type> [<argument> ...]

Table of equation types :

Type#	Desc	Arguments
0		Arg		<arg>
1		Reg		<var#>
2		Not		<arg>
3		Binop	<op# *4> <arg> <arg>
4		Mux		<arg> <arg:when false> <arg:when true>
5		Rom		<addr_size> <word_size> <arg:read_addr>
6		Ram		<addr_size> <word_size> <arg:read_addr> <arg:write_enable>
					<arg:write_addr> <arg:data>
7		Concat	<arg> <arg>
8		Slice	<begin> <end> <arg>
9		Select	<id> <arg>

An argument (<arg> or <arg:*>) can be either a binary value, represented by the
bits in standard order defined above, either a reference to another variable,
with the syntax $<var_id>

*4 : The operators are :
0	OR
1	XOR
2	AND
3	NAND
	
This syntax is formalized by the reference implementation provided in the source
file csim/load.h.

TODO : to simplify the internals, create an intermediate format where <arg> can
be nothing but a reference to another variable. All constants will then have to
be assigned to a constant-type variable that can be counted among the inputs (or
whatever - anyway, no need to recalculate them at every iteration).


The Input/Output format
-----------------------

The C simulator is capable of reading inputs for each step from a file (by
default stdin, but can be redirected from a file using the -in option) and of
writing the outputs at each step to a file (by default stdout, but can be
redirected with -out).

The input format is extremely straightforward : at each step, read a line
containing for each input variable, *in the order given in the program file*,
either a binary value (represented by a series of bits given in the standard
order), either a decimal value prefixed with a slash (/), which is then
converted to binary according to the standard representation defined above.

The output format contains at each step one line for each output variable, in
the format :
<variable name>\t<binary representation>\t<decimal representation>
The output contains an empty line at the end of every cycle.


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 :
	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 compiler will detect the prefix `decode7` in the variable name
decode7_128, and use the ROM from the file specified on the command line.

Suggested format for the ROM files :

<address width> <word size>
<data>

The data is composed of 2^(address width) values separated by spaces. If they
have no prefix, they are read as binary. If they have a / prefix, they are read
as decimal (this enables the use of whichever representation is preferred).